Re: JOP as SOPC component

"Martin Schoeberl" <mschoebe@xxxxxxxxxxxxxxxxx> wrote in message
news:44f4e0c4$0$11352$3b214f66@xxxxxxxxxxxxxxxxxxxxxx
proprietary Altera design, or are there open source implementations
available?" The switch fabric itself can easily be written, it is on the
order of six lines of code per interface for a point to point connection,
there is nothing really magic in what Altera spits out of SOPC Builder
based

I think that this is actually the power of SOPC builder. It will
do all your glue logic stuff for the interconnect (address
decoding, byte order managing, byte enable on write,...).

And that's a lot more than 6 lines of code ;-)

You missed my caveats about the 6 lines of code being 'per interface' for a
'point to point connection'. Below is the six lines of code that will
implement what SOPC Builder spits out for such an interface when neither
master or slave has latency.
1: slave_chipselect <= (master_read or master_write) and
To_Std_Logic(master_address = Hard_coded_Address_range);
2: slave_write <= master_write;
3: slave_read <= master_read;
4: slave_writedata <= master_writedata;
5: master_waitrequest <= slave_chipselect and slave_waitrequest;
6: master_readdata <= slave_readdata;

When you have a latency aware master and a slave then there is the one
additional line of code to connect the two 'readdatavalid' signals.
Obviously these are the most simple cases, but surprisingly enough I've
found that between functional blocks on a single chip the six lines (or
seven) are in many cases sufficient.

When you get into the various forms that a master and slave can take the
number of lines of code per interface can balloon quite rapidly since you
need to take into account differences in data bus widths, connecting latency
aware master/slaves to ones that are not, multiple bus masters, etc. I
completely agree with you though about the power of SOPC Builder as a tool
to implement that somewhat rote exercise of interconnect based on
information solely in the .PTF file.

I did run into several problems in using SOPC Builder that generated several
service requests to Altera that resulted in
- Me having to completely replace the SOPC Builder generated code. But
since I was connecting all Avalon components it was a tedious (but totally
straightforward) process.
- Getting a T-shirt from Altera for pointing out the various deficiencies in
their tool....and I thought the tool, having been around for several years,
would've been a bit sturdier.
- Promises from Altera to improve the tool. Supposedly it is much better in
Quartus 6, I haven't tried yet but I will because even if I end up having to
go down the same path, what SOPC Builder brings to the table has the
potential to replace a good chunk of tedious, mindless work.


an open source version of this connection logic, but whether simple use
of the Avalon bus without also targetting an Altera device (even if no
Altera software is involved) is violating anything is an open legal
question as you've pointed out (I'm guessing that it might but not really
sure).

AFAIK the bus definition is kind of open-source - free.
That's my belief but I haven't really investigated whether that is true or
not.

However,
I'm sure you're not allowed to use the SOPC builder generated
VHDL code on a Xilinx device ;-)
That is definitely the case.

BTW: I asked Altera Austria about a related topic: Is it allowed
to 'use' the DRAM controller in an open-source environment (means
can I upload the VHDL code to a web server). However, they had
no real answare to this. They sayed that the SDRAM controller
does is part of NIOS and does only work with NIOS. Therefore,
one has to buy a NIOS license. But it works quite well with JOP
too ;-)
I'm not sure that's really true. I think the SDRAM and DDR controllers are
bundled as a part of Altera's Megacore which is a part of Quartus. You can
use all of those and SOPC Builder without a NIOS license. I'm also thinking
though that the DRAM controller itself would not be open source since it was
generated by Altera for use by people that they would like to target Altera
devices.


Section 2
In the paragraph starting "The third issue is..." you ask the question
"Why not force the slaves to hold the data on the output registers as
long as there is no new transaction?" A couple follow up questions to
that though would be
- What is a SimpCon slave to do if there IS a new transaction before the
old one has been acknowledged?

good question ;-) It depends on the pipeline level. It can accept
it. But this is not directly related on the request to 'just'
keep the data valid until a newer one is available (and was
requested).
I was going the devil's advocate route and asking what 'should' happen since
if a new read starts before the old one has been acknowledged this implies
that the slave would then have to keep a queue of 'previously requested but
not yet read acknowledged' data somewhere. Presumably when that queue fills
up the slave would have to have someway to say 'Stop! I can't take it
anymore' which I *think* might mean that the SimpCon slave would keep
rdy_cnt set to 3.


- Does the SimpCon fabric prevent this from happening? (I think it does,
but not exactly sure)

It is the master who decides when to issue a new request
and when to leave the slave with the last data.
And this may also be the answer to the above that a SimpCon master is not
allowed to initiate a new request until it has acknowledged reading the
previous.

having the master 'know' the latency about the 'slave' would seem to be
cheating (since this wasn't required by the SimpCon implementation as I
had thought) but I guess I'll fall back to what Tommy mentioned earlier
that since JOP was optomized for SimpCon in the first place it implies
that an Avalon/SimpCon bridge must be built and such bridges can tend to
be either

about cheating and bridge: I'm allready cheating on the Avalon
interface (as mentioned in an earlier post) to generate the
address/control/data holding in the master - I switch between
the original single cycle register at the first cycle
and a hold register on the following cycles - that's not
allowed in the original spec.
Actually I'm not sure that what you had is cheating. Avalon requires
address, read, write and writedata to hold when the master receives
waitrequest but it also says that it really only cares about signals at the
rising edge of the clock. The SOPC Builder generated code though generates
an assert if any of those signals change without regarding the clock. This
to me is an overly agressive assert that I think goes beyond what the Avalon
bus specifies. Maybe a question for Altera.

be). Had JOP been optomized for Avalon to begin with would the numbers
be any better without any cheating? That's sort of the open question and
I'm not necessarily expecting an answer.

Mmh, hard to say. I implemented the memory interface without
any SoC interconnect in mind - just tried to get the best
performance on SRAMs. The bus thing came very late in the
design. So it looks like I'm now defining a bus that 'fits'
to the way the original memory interface of JOP was.
However, perhaps that's not that bad as a new idea for a
differnt bus comes up ;-)
No, in fact it's generally a good idea since you've at least used that bus
definition to implement a real something.


My main interest in the thread was in understanding what sort of
bottlenecks might be lurking in Avalon that I'm not aware of. A couple
areas of 'possible' weakness for Avalon that I am aware of are:
- It can hang (there is no requirement for a max time for a cycle).
Something to be aware of, but generally not an issue since whoever is
designing the slave components had better address this and not allow for
a hang to occur.
- No notion of a 'retry'. Again, given the environment of being on a
chip, the slave design shouldn't be allowe to say 'try again later
please' so I don't think this should be an actual design issue, just
something to be aware of.

Implementing those two features makes your bus (and interfacing)
way more complicated. AFAIK OPB does it, but you end up with
so many signals...
I agree. It's good to be aware of the issues but I don't think they are
that important in many cases and not worth overcomplicating the bus to
accomodate it.


- Can't have pending reads from multiple slaves. I suppose this could be
important to some, it hasn't for me.

That's more an issue of the interconnect logic and not the
bus definition.
Specifically logic resource usage in the interconnect. Allowing for this
feature would bloat the interconnect logic and, in many cases, such bloat
would not be required....at best, if such a thing is available you, as the
designer, would like to be able to specify whether such a thing is really
needed so you cna make an informed decision on the tradeoff.


You can do single cycle pipelined read with a latency of two
cycles (compared to just a single one in AMBA AHB). Perhaps
I should provide that example too. When the slave supports it
you can issue a new read request when rdy_cnt is 2. When
you do it than rdy_cnt will stay at 2 - the 2 cycle pipelining.
OK. Not sure what the pipeline delay through an off the shelf DRAM
controller is. It might be more than two though even when things are
flowing along (i.e. not refreshes are occuring). I'm guessing that it is
probably less than 8 which might mean that one more bit to the rdy_cnt might
allow you to connect cleaner to DRAMs and get full performance.


BTW: I don't know VSIA. Any link to it?

http://www.vsia.org/documents/vsiadocuments.htm

I'm aware of, but I haven't designed anything to their 'on chip bus'
specification. I get the impression from what I've heard that the ASIC guys
may use it. Since our volumes never justify the NRE to do an ASIC, we use
FPGAs so I've been more focused on tools and techniques to improve design
productivity inside an FPGA.

Completely agree - will remove this 'controversal' as this thread
is more 'constructive'.

Thus ends the controversy over the use of the word 'controversal'.

KJ


.

Relevant Pages

  • Re: i2c/rs232 converter
    ... I have an i2c bus which has a master already. ... interface) and asynchronous serial interface and program it to ... The TWI in AVR's can be used a a slave interface. ...
    (comp.arch.embedded)
  • Re: a question in SystemVerilog
    ... I'm writing a verification envir in SV, the envir contains 4 masters, ... have the same interface, I created one interface, but I should use a ... masters and slaves connected to a single bus. ... master or slave connected to a bus. ...
    (comp.lang.verilog)
  • 6.0-R, ICH6 and SATA problems
    ... from master to slave and back again with no change. ... ATA channel 0: ... <ACPI PCI bus> on pcib0 ... 2 ports with 2 removable, ...
    (freebsd-questions)
  • Re: Overclocking the c64
    ... >> I'm just trying to get more info on the dot clock. ... > What do you mean with "interface it to the PC bus"? ... > cartridge port of the C64. ...
    (comp.sys.cbm)
  • Re: RFC on VHDL LRM 93[8.4.1]
    ... that the way you defined the slave and master that they already were ... would perform address decoding and arbitration functions. ... and slave side then this single entity can implement the bus protocol. ...
    (comp.lang.vhdl)
Loading