[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [openrisc] Understanding traffic cop
If you would be able to implement it, I'd say just check in your changes to
traffic cop to the cvs. If you only added comments, then please check in. If
you changed RTL, then please make sure not to break something. There is no
ATS to check RTL. If simulation works, then this is a good sign that RTL is
OK.
regards,
Damjan
----- Original Message -----
From: "Damon Brantley" <brantley@mcloudteleco.com>
To: <openrisc@opencores.org>
Sent: Monday, July 07, 2003 9:34 PM
Subject: Re: [openrisc] Understanding traffic cop
> Thanks for the excellent explantion. That allowed me to understand how
things
> are organized. I was also able to resolve the err problem mentioned in my
> other post.
>
> I have added in extra comments to my local copy of tc_top as you
suggested.
> Should I try to commit that directly or just post a patch.
>
> Another issue I have that I hoped would go away when I fixed this problem.
>
> For some reason xst is optimizing everything out. The cpu, tc_top and
> everything else . Everything is working as expected in simulation, so
> I think my logic is good. Usually when everything disappears like this it
> means
> I did something wrong with a clock or a reset, but I can usually find it
> pretty quick
> in simulation. Not this time though.
>
> Regards,
> Damon
>
> At 04:33 PM 7/7/2003 -0700, you wrote:
> >> Some of the things I am having problems with are:
> >> 1. What are the signals with names like xi0_wb_dat_o or yi0_wb_dat_o
for
> >> example.
> >> These ultimately are getting or'ed together to produce the output
> >> i0_wb_dat_o, but I do not understand
> >> the separation.
> >
> >There are two "channels". One channel going to target 0 and the other
> >channel going to targets 1-8. Number of channels means how many
initiators
> >can independently access targets.
> >
> >Targets is basically slave peripherals. Initiators are masters.
> >Initiator/targets are used in case of traffic cop not to confuse with
> >masters/slaves on traffic cop and in the system (from traffic point of
view
> >master can be something else then from master point of view, rememberwhen
> >you attach master to a traffic cop, traffic cop interface can be
considered
> >a slave, or do you name the interface as master because you connect
master -
> >anyway it is a matter of convention, so I used initiators and targets,
> >similar to PCI convention).
> >
> >So in this case you have 8 initators going to target 0 and the same 8
> >initiators (as in the second channel) going to targets 1-8 (so targets
1-8
> >can only be access one at a time, while target 0 is independent). Signals
> >coming from target 0 are prefixed with x and those in the second channel
are
> >prefixed with y. These of course need to be ORed together because at the
end
> >there is only one set of initiators.
> >
> >> 2. What is target 0 and initiator 0. Are these real devices on the bus
> >like
> >> (cpu and memory) or is this
> >> a reference to traffic cop itself.
> >
> >Khm, not sure what you mean. Initiator 0 is not reference to real
devices,
> >you can connect whatever you want. But at the end a master device will be
> >connected to initiator 0, for example the cpu. Target 0 will usually be
> >connected to memory, to allow independent access to memory while for
example
> >UARTs etc will be connected to target 1-8 as they are slow and don't have
to
> >be accessible independently.
> >
> >> 3. What does the comment // From initiators to targets 1-8 (lower part)
> >and
> >> // From initiators to targets 1-8 (upper part)
> >> mean?
> >
> >The traffic cop is basically split into two parts, lower and upper. There
> >are two upper parts, each for a channel. For example all initiators are
> >"merged and arbitrated" together into first channel and result of merging
> >goes to target 0. This is the case with t0_ch instance of module
tc_mi_to_st
> >(module name means "traffic cop multiple initiators to single target").
So
> >for first channel going to target 0 there is no lower part.
> >
> >There is also t18_ch_upper instances, this one also "merges / arbitrates"
> >the same initiators into second channel going to targets 1-8. (here
> >tc_mi_to_st would better read as in "traffic cop multiple initiator to
> >single channel" instead of "single target", but the name single target is
> >because the module itself is indeed goign to a single target, however
> >because of the lower part that is demuxing it goes to multiple targets).
> >
> >So as indicated above, instance t18_ch_lower of module tc_si_to_mt
(traffic
> >cop single initiaror to multiple targets) is used to demux second channel
> >and connect multiple targets. So together upper and lower part merge/mux
> >targets 1-8 to initiators.
> >
> >> 4. What are the z signals like z_wb_cyc_i for?
> >
> >z is basically second channel. So between muxed initiators (upper part)
and
> >demux targets (lower part).
> >
> >>
> >> Ultimately I know this is a multiplexer, but the devil is in the
details.
> >> If there are some other docs I should be
> >> looking at, let me know.
> >
> >If you can make more comments in the traffic cop based on what I have
> >written here, the next guy will have less questions to ask. ;-)
> >
> >regards,
> >Damjan
> >
> >>
> >> Thanks,
> >> Damon
> >>
> >> --
> >> To unsubscribe from openrisc mailing list please visit
> >http://www.opencores.org/mailinglists.shtml
> >>
> >
> >--
> >To unsubscribe from openrisc mailing list please visit
> http://www.opencores.org/mailinglists.shtml
> >
>
> --
> To unsubscribe from openrisc mailing list please visit
http://www.opencores.org/mailinglists.shtml
>
--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml