Re: [openrisc] Understanding traffic cop

["Damon Brantley" <brantley@mcloudteleco.com>]

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