LOGIN   :::   RECOVER PASS   :::   GET ACCOUNT    
Browse
  • Projects
  • Code (CVS)
  • Forums
  • News
  • Articles
  • Polls
  •  
    OpenCores
  • FAQ
  • CVS HowTo
  • Mission
  • Media
  • Tools
  • Advertise
  • Mirrors
  • Logos
  • Contact us
  • Find Resources
  • Job Opportunity
  •  
    Tools
  • Search
      
  • Download Cores (CVSGet)
  •  
    More
  • Wishbone
  • Perlilog
  • EDA tools
  • OpenTech CD
  •  
    Navigation: All forums > Openrisc > Message List > Message Post

    Message

    Reply | Reply all
    Date Prev | Date Next | Thread Prev | Thread Next Date Index | Thread Index

    From: "Damon Brantley" <brantley@m...>
    Date: Mon, 07 Jul 2003 23:34:13 -0500
    Subject: Re: [openrisc] Understanding traffic cop
    Top

    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
    >>
    >> 
    >>
    >
    >
    >
    
    
    
    

    ReferenceAuthor
    [openrisc] Understanding traffic copDamon Brantley
    Re: [openrisc] Understanding traffic copDamjan Lampret

    Follow upAuthor
    Re: [openrisc] Understanding traffic copDamjan Lampret

     
    Copyright (c) 1999 OPENCORES.ORG. All rights reserved.