Sign in
Search fpga-cpu
Subscribe to fpga-cpu
fpga-cpu by Keywords
Altera | CISCifying | IDE | ISA | Java | JHDL | JTAG | LBU | MicroBlaze | PAR | PCI | RISC | SoC | Spartan | Transputers | Verilog | VHDL | Virtex | VLIW | WebPack | Xilinx | Xsoc | YARD-1A
Ads
Discussion Groups
Discussion Groups | FPGA-CPU | Re: Wishbone comments - SimpCon
This list is for discussion of the design and implementation of field-programmable gate array based processors and integrated systems. It is also for discussion and community support of the XSOC Project (see http://www.fpgacpu.org/xsoc).
Re: Wishbone comments - SimpCon - Martin Schoeberl - Nov 24 18:30:00 2005
Hi Kolja and all,
>> to get a draft of your spec.
...
> The draft of the spec at the moment are few sketches on real
> paper - takes some time to draw all diagrams for a document
> (BTW does anybody know a tool for quick drawing of timing
> diagrams). The draft is still not written, but I've implemented it in JOP
for the Cyclone and for the Spartan-3. Both sub-projects use
now the same memory interface and the Spartan version
benefits from the bytecode block cache that was up to now
only available in the Cyclone version.
If you are interested in the implementation download the sources
from [1] or from the CVS [2] at opencores.org. You can find
the SimpCon master in mem_sc.vhd and a slave for a 32-bit SRAM
in sc_sram32.vhd. The master uses a pipeline level of 2 for
the bytecode cache load. There is also a ModelSim simulation
available at modelsim/sc.bat.
To Kolja: Perhaps you can implement the 16-bit SRAM interface
for the Trenz Retrocomputing board? Than we have another example
for the SimpCon interface and I get a feedback from you how
simple it is to implement a slave (take a look into mem_trenz.vhd
for the 'old', but current memory interface for your board).
A voting question to the group: What kind of SoC interconnect
are you using: Wishbone, Xilinx/IBM OPB, Avalon, AMBA or your
own home brewed interface?
Cheers,
Martin
[1] http://www.jopdesign.com/download.jsp
[2] cvs -d :pserver:anonymous@anon...:/cvsroot/anonymous -z9 co -P jop
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
...
> The draft of the spec at the moment are few sketches on real
> paper - takes some time to draw all diagrams for a document
> (BTW does anybody know a tool for quick drawing of timing
> diagrams). The draft is still not written, but I've implemented it in JOP
for the Cyclone and for the Spartan-3. Both sub-projects use
now the same memory interface and the Spartan version
benefits from the bytecode block cache that was up to now
only available in the Cyclone version.
If you are interested in the implementation download the sources
from [1] or from the CVS [2] at opencores.org. You can find
the SimpCon master in mem_sc.vhd and a slave for a 32-bit SRAM
in sc_sram32.vhd. The master uses a pipeline level of 2 for
the bytecode cache load. There is also a ModelSim simulation
available at modelsim/sc.bat.
To Kolja: Perhaps you can implement the 16-bit SRAM interface
for the Trenz Retrocomputing board? Than we have another example
for the SimpCon interface and I get a feedback from you how
simple it is to implement a slave (take a look into mem_trenz.vhd
for the 'old', but current memory interface for your board).
A voting question to the group: What kind of SoC interconnect
are you using: Wishbone, Xilinx/IBM OPB, Avalon, AMBA or your
own home brewed interface?
Cheers,
Martin
[1] http://www.jopdesign.com/download.jsp
[2] cvs -d :pserver:anonymous@anon...:/cvsroot/anonymous -z9 co -P jop
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Wishbone comments - SimpCon - Richard John - Nov 25 21:35:00 2005
I have used Chronology's TimingDesigner for drawing timing diagram.
This tool allowed me to not only draw timing diagram but also analyze and budget the entire path include clock uncertainity.
It has been a while since I used this tool, but back then it also had a spreadsheet type interface, which allowed me to to what-if analysis on various components of the path.
Hope this helps
Richard
fpga-cpu@fpga... wrote:
There are 2 messages in this issue.
Topics in this digest:
1. Re: Wishbone comments - SimpCon
From: "Martin Schoeberl"
2. Re: Wishbone comments
From: Kolja Sulimma ________________________________________________________________________
________________________________________________________________________
Message: 1
Date: Thu, 24 Nov 2005 23:30:16 +0100
From: "Martin Schoeberl"
Subject: Re: Wishbone comments - SimpCon
Hi Kolja and all, >> to get a draft of your spec.
...
> The draft of the spec at the moment are few sketches on real
> paper - takes some time to draw all diagrams for a document
> (BTW does anybody know a tool for quick drawing of timing
> diagrams). The draft is still not written, but I've implemented it in JOP
for the Cyclone and for the Spartan-3. Both sub-projects use
now the same memory interface and the Spartan version
benefits from the bytecode block cache that was up to now
only available in the Cyclone version.
If you are interested in the implementation download the sources
from [1] or from the CVS [2] at opencores.org. You can find
the SimpCon master in mem_sc.vhd and a slave for a 32-bit SRAM
in sc_sram32.vhd. The master uses a pipeline level of 2 for
the bytecode cache load. There is also a ModelSim simulation
available at modelsim/sc.bat.
To Kolja: Perhaps you can implement the 16-bit SRAM interface
for the Trenz Retrocomputing board? Than we have another example
for the SimpCon interface and I get a feedback from you how
simple it is to implement a slave (take a look into mem_trenz.vhd
for the 'old', but current memory interface for your board).
A voting question to the group: What kind of SoC interconnect
are you using: Wishbone, Xilinx/IBM OPB, Avalon, AMBA or your
own home brewed interface?
Cheers,
Martin
[1] http://www.jopdesign.com/download.jsp
[2] cvs -d :pserver:anonymous@anon...:/cvsroot/anonymous -z9 co -P jop ________________________________________________________________________
________________________________________________________________________
Message: 2
Date: Fri, 25 Nov 2005 15:49:57 +0100
From: Kolja Sulimma
Subject: Re: Wishbone comments
Martin Schoeberl schrieb:
>>Anyway, I am a big fan of pipelined busses (ever seen the SCI link
>>controller interface?) so I would like
>>
>>
>
>No, have not seen it. Do you have a link to it handy? No. Only the SCI spec, not the link controller.
>The idea for (some) pipeline support is twofold:
>
>1.) The slave will provide more information than a single ack
>or wait states. It will (if it is capable to do) signal the
>number of clock cycles remaining till the read data is available
>(or the write has finished) to the master. This feature allows
>the pipelined master to prepare for the upcomming read.
>
>2.) If the slave can provide pipelining the master can use
>overlapped wr or rd requests. The slave has a static output
>port that tells how many pipeline stages are available.
>I call this 'pipeline level':
> 0 means non overlapping
> 1 a new rd/wr request can be issued in the same cycle
> when the former data is read.
> 2 one earlier and
> 3 is the maximum level where you get full pipelining
> on the basic read cycle with one wait state
> (command - read - read - result). >
I do not like the concept of telling the master at the beginning of each
cycle what the latency will be.
But I believe that you get what you want simply by using split
transactions.
The slave acknowledges that it latched the address and control
information and the master is free to
supply the next address to the next or the same slave.
Pipelining within a single slave can have any amount of levels. The
slave just keeps acknowleding addresses
and after a while starts acknowleding data.
Having multiple outstanding read transactions to different slaves is
tricky and probably not worth the effort.
I would suggest limiting the bus to one or none outstanding transaction
to other slaves. Otherwise it would be
necessary to keep a queue of outstanding slaves and select the right
data source at the right time.
Unfortunately I am not available at the moment to implement any
hardware. To many outstanding transactions ;-)
Kolja
________________________________________________________________________
________________________________________________________________________ To post a message, send it to: fpga-cpu@fpga...
To unsubscribe, send a blank message to: fpga-cpu-unsubscribe@fpga...
------------------------------------------------------------------------
Yahoo! Groups Links
------------------------------------------------------------------------
---------------------------------
Yahoo! Music Unlimited - Access over 1 million songs. Try it free.
[Non-text portions of this message have been removed]
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
This tool allowed me to not only draw timing diagram but also analyze and budget the entire path include clock uncertainity.
It has been a while since I used this tool, but back then it also had a spreadsheet type interface, which allowed me to to what-if analysis on various components of the path.
Hope this helps
Richard
fpga-cpu@fpga... wrote:
There are 2 messages in this issue.
Topics in this digest:
1. Re: Wishbone comments - SimpCon
From: "Martin Schoeberl"
2. Re: Wishbone comments
From: Kolja Sulimma ________________________________________________________________________
________________________________________________________________________
Message: 1
Date: Thu, 24 Nov 2005 23:30:16 +0100
From: "Martin Schoeberl"
Subject: Re: Wishbone comments - SimpCon
Hi Kolja and all, >> to get a draft of your spec.
...
> The draft of the spec at the moment are few sketches on real
> paper - takes some time to draw all diagrams for a document
> (BTW does anybody know a tool for quick drawing of timing
> diagrams). The draft is still not written, but I've implemented it in JOP
for the Cyclone and for the Spartan-3. Both sub-projects use
now the same memory interface and the Spartan version
benefits from the bytecode block cache that was up to now
only available in the Cyclone version.
If you are interested in the implementation download the sources
from [1] or from the CVS [2] at opencores.org. You can find
the SimpCon master in mem_sc.vhd and a slave for a 32-bit SRAM
in sc_sram32.vhd. The master uses a pipeline level of 2 for
the bytecode cache load. There is also a ModelSim simulation
available at modelsim/sc.bat.
To Kolja: Perhaps you can implement the 16-bit SRAM interface
for the Trenz Retrocomputing board? Than we have another example
for the SimpCon interface and I get a feedback from you how
simple it is to implement a slave (take a look into mem_trenz.vhd
for the 'old', but current memory interface for your board).
A voting question to the group: What kind of SoC interconnect
are you using: Wishbone, Xilinx/IBM OPB, Avalon, AMBA or your
own home brewed interface?
Cheers,
Martin
[1] http://www.jopdesign.com/download.jsp
[2] cvs -d :pserver:anonymous@anon...:/cvsroot/anonymous -z9 co -P jop ________________________________________________________________________
________________________________________________________________________
Message: 2
Date: Fri, 25 Nov 2005 15:49:57 +0100
From: Kolja Sulimma
Subject: Re: Wishbone comments
Martin Schoeberl schrieb:
>>Anyway, I am a big fan of pipelined busses (ever seen the SCI link
>>controller interface?) so I would like
>>
>>
>
>No, have not seen it. Do you have a link to it handy? No. Only the SCI spec, not the link controller.
>The idea for (some) pipeline support is twofold:
>
>1.) The slave will provide more information than a single ack
>or wait states. It will (if it is capable to do) signal the
>number of clock cycles remaining till the read data is available
>(or the write has finished) to the master. This feature allows
>the pipelined master to prepare for the upcomming read.
>
>2.) If the slave can provide pipelining the master can use
>overlapped wr or rd requests. The slave has a static output
>port that tells how many pipeline stages are available.
>I call this 'pipeline level':
> 0 means non overlapping
> 1 a new rd/wr request can be issued in the same cycle
> when the former data is read.
> 2 one earlier and
> 3 is the maximum level where you get full pipelining
> on the basic read cycle with one wait state
> (command - read - read - result). >
I do not like the concept of telling the master at the beginning of each
cycle what the latency will be.
But I believe that you get what you want simply by using split
transactions.
The slave acknowledges that it latched the address and control
information and the master is free to
supply the next address to the next or the same slave.
Pipelining within a single slave can have any amount of levels. The
slave just keeps acknowleding addresses
and after a while starts acknowleding data.
Having multiple outstanding read transactions to different slaves is
tricky and probably not worth the effort.
I would suggest limiting the bus to one or none outstanding transaction
to other slaves. Otherwise it would be
necessary to keep a queue of outstanding slaves and select the right
data source at the right time.
Unfortunately I am not available at the moment to implement any
hardware. To many outstanding transactions ;-)
Kolja
________________________________________________________________________
________________________________________________________________________ To post a message, send it to: fpga-cpu@fpga...
To unsubscribe, send a blank message to: fpga-cpu-unsubscribe@fpga...
------------------------------------------------------------------------
Yahoo! Groups Links
------------------------------------------------------------------------
---------------------------------
Yahoo! Music Unlimited - Access over 1 million songs. Try it free.
[Non-text portions of this message have been removed]
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Re: Wishbone comments - SimpCon - Martin Schoeberl - Dec 6 10:36:00 2005
Thanks for the info. However, just for drawing TimingDesigner
i a littel bit too expensive for me (L 1700,-).
BTW: SimpCon is now a project at opencores:
http://www.opencores.org/projects.cgi/web/simpcon/overview
Martin
----- Original Message -----
From: "Richard John" <richard_john_81@rich...>
To: <fpga-cpu@fpga...>
Sent: Saturday, November 26, 2005 2:35 AM
Subject: [fpga-cpu] Re: Wishbone comments - SimpCon >I have used Chronology's TimingDesigner for drawing timing diagram.
>
> This tool allowed me to not only draw timing diagram but also analyze and budget the entire path include clock uncertainity.
>
> It has been a while since I used this tool, but back then it also had a spreadsheet type interface, which allowed me to to
> what-if analysis on various components of the path.
>
> Hope this helps
> Richard
>
> fpga-cpu@fpga... wrote:
> There are 2 messages in this issue.
>
> Topics in this digest:
>
> 1. Re: Wishbone comments - SimpCon
> From: "Martin Schoeberl"
> 2. Re: Wishbone comments
> From: Kolja Sulimma > ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 1
> Date: Thu, 24 Nov 2005 23:30:16 +0100
> From: "Martin Schoeberl"
> Subject: Re: Wishbone comments - SimpCon
>
> Hi Kolja and all,
>
>>
>>> to get a draft of your spec.
> ...
>> The draft of the spec at the moment are few sketches on real
>> paper - takes some time to draw all diagrams for a document
>> (BTW does anybody know a tool for quick drawing of timing
>> diagrams).
>>
>
> The draft is still not written, but I've implemented it in JOP
> for the Cyclone and for the Spartan-3. Both sub-projects use
> now the same memory interface and the Spartan version
> benefits from the bytecode block cache that was up to now
> only available in the Cyclone version.
>
> If you are interested in the implementation download the sources
> from [1] or from the CVS [2] at opencores.org. You can find
> the SimpCon master in mem_sc.vhd and a slave for a 32-bit SRAM
> in sc_sram32.vhd. The master uses a pipeline level of 2 for
> the bytecode cache load. There is also a ModelSim simulation
> available at modelsim/sc.bat.
>
> To Kolja: Perhaps you can implement the 16-bit SRAM interface
> for the Trenz Retrocomputing board? Than we have another example
> for the SimpCon interface and I get a feedback from you how
> simple it is to implement a slave (take a look into mem_trenz.vhd
> for the 'old', but current memory interface for your board).
>
> A voting question to the group: What kind of SoC interconnect
> are you using: Wishbone, Xilinx/IBM OPB, Avalon, AMBA or your
> own home brewed interface?
>
> Cheers,
> Martin
>
> [1] http://www.jopdesign.com/download.jsp
> [2] cvs -d :pserver:anonymous@anon...:/cvsroot/anonymous -z9 co -P jop > ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 2
> Date: Fri, 25 Nov 2005 15:49:57 +0100
> From: Kolja Sulimma
> Subject: Re: Wishbone comments
>
> Martin Schoeberl schrieb:
>
>>>Anyway, I am a big fan of pipelined busses (ever seen the SCI link
>>>controller interface?) so I would like
>>>
>>>
>>
>>No, have not seen it. Do you have a link to it handy?
>>
>>
> No. Only the SCI spec, not the link controller.
>
>>The idea for (some) pipeline support is twofold:
>>
>>1.) The slave will provide more information than a single ack
>>or wait states. It will (if it is capable to do) signal the
>>number of clock cycles remaining till the read data is available
>>(or the write has finished) to the master. This feature allows
>>the pipelined master to prepare for the upcomming read.
>>
>>2.) If the slave can provide pipelining the master can use
>>overlapped wr or rd requests. The slave has a static output
>>port that tells how many pipeline stages are available.
>>I call this 'pipeline level':
>> 0 means non overlapping
>> 1 a new rd/wr request can be issued in the same cycle
>> when the former data is read.
>> 2 one earlier and
>> 3 is the maximum level where you get full pipelining
>> on the basic read cycle with one wait state
>> (command - read - read - result).
>>
>>
>>
> I do not like the concept of telling the master at the beginning of each
> cycle what the latency will be.
> But I believe that you get what you want simply by using split
> transactions.
> The slave acknowledges that it latched the address and control
> information and the master is free to
> supply the next address to the next or the same slave.
> Pipelining within a single slave can have any amount of levels. The
> slave just keeps acknowleding addresses
> and after a while starts acknowleding data.
> Having multiple outstanding read transactions to different slaves is
> tricky and probably not worth the effort.
> I would suggest limiting the bus to one or none outstanding transaction
> to other slaves. Otherwise it would be
> necessary to keep a queue of outstanding slaves and select the right
> data source at the right time.
>
> Unfortunately I am not available at the moment to implement any
> hardware. To many outstanding transactions ;-)
>
> Kolja >
>
> ________________________________________________________________________
> ________________________________________________________________________ > To post a message, send it to: fpga-cpu@fpga...
> To unsubscribe, send a blank message to: fpga-cpu-unsubscribe@fpga...
> ------------------------------------------------------------------------
> Yahoo! Groups Links >
>
> ------------------------------------------------------------------------ >
>
> ---------------------------------
> Yahoo! Music Unlimited - Access over 1 million songs. Try it free.
>
> [Non-text portions of this message have been removed] > To post a message, send it to: fpga-cpu@fpga...
> To unsubscribe, send a blank message to: fpga-cpu-unsubscribe@fpga...
> Yahoo! Groups Links
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
i a littel bit too expensive for me (L 1700,-).
BTW: SimpCon is now a project at opencores:
http://www.opencores.org/projects.cgi/web/simpcon/overview
Martin
----- Original Message -----
From: "Richard John" <richard_john_81@rich...>
To: <fpga-cpu@fpga...>
Sent: Saturday, November 26, 2005 2:35 AM
Subject: [fpga-cpu] Re: Wishbone comments - SimpCon >I have used Chronology's TimingDesigner for drawing timing diagram.
>
> This tool allowed me to not only draw timing diagram but also analyze and budget the entire path include clock uncertainity.
>
> It has been a while since I used this tool, but back then it also had a spreadsheet type interface, which allowed me to to
> what-if analysis on various components of the path.
>
> Hope this helps
> Richard
>
> fpga-cpu@fpga... wrote:
> There are 2 messages in this issue.
>
> Topics in this digest:
>
> 1. Re: Wishbone comments - SimpCon
> From: "Martin Schoeberl"
> 2. Re: Wishbone comments
> From: Kolja Sulimma > ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 1
> Date: Thu, 24 Nov 2005 23:30:16 +0100
> From: "Martin Schoeberl"
> Subject: Re: Wishbone comments - SimpCon
>
> Hi Kolja and all,
>
>>
>>> to get a draft of your spec.
> ...
>> The draft of the spec at the moment are few sketches on real
>> paper - takes some time to draw all diagrams for a document
>> (BTW does anybody know a tool for quick drawing of timing
>> diagrams).
>>
>
> The draft is still not written, but I've implemented it in JOP
> for the Cyclone and for the Spartan-3. Both sub-projects use
> now the same memory interface and the Spartan version
> benefits from the bytecode block cache that was up to now
> only available in the Cyclone version.
>
> If you are interested in the implementation download the sources
> from [1] or from the CVS [2] at opencores.org. You can find
> the SimpCon master in mem_sc.vhd and a slave for a 32-bit SRAM
> in sc_sram32.vhd. The master uses a pipeline level of 2 for
> the bytecode cache load. There is also a ModelSim simulation
> available at modelsim/sc.bat.
>
> To Kolja: Perhaps you can implement the 16-bit SRAM interface
> for the Trenz Retrocomputing board? Than we have another example
> for the SimpCon interface and I get a feedback from you how
> simple it is to implement a slave (take a look into mem_trenz.vhd
> for the 'old', but current memory interface for your board).
>
> A voting question to the group: What kind of SoC interconnect
> are you using: Wishbone, Xilinx/IBM OPB, Avalon, AMBA or your
> own home brewed interface?
>
> Cheers,
> Martin
>
> [1] http://www.jopdesign.com/download.jsp
> [2] cvs -d :pserver:anonymous@anon...:/cvsroot/anonymous -z9 co -P jop > ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 2
> Date: Fri, 25 Nov 2005 15:49:57 +0100
> From: Kolja Sulimma
> Subject: Re: Wishbone comments
>
> Martin Schoeberl schrieb:
>
>>>Anyway, I am a big fan of pipelined busses (ever seen the SCI link
>>>controller interface?) so I would like
>>>
>>>
>>
>>No, have not seen it. Do you have a link to it handy?
>>
>>
> No. Only the SCI spec, not the link controller.
>
>>The idea for (some) pipeline support is twofold:
>>
>>1.) The slave will provide more information than a single ack
>>or wait states. It will (if it is capable to do) signal the
>>number of clock cycles remaining till the read data is available
>>(or the write has finished) to the master. This feature allows
>>the pipelined master to prepare for the upcomming read.
>>
>>2.) If the slave can provide pipelining the master can use
>>overlapped wr or rd requests. The slave has a static output
>>port that tells how many pipeline stages are available.
>>I call this 'pipeline level':
>> 0 means non overlapping
>> 1 a new rd/wr request can be issued in the same cycle
>> when the former data is read.
>> 2 one earlier and
>> 3 is the maximum level where you get full pipelining
>> on the basic read cycle with one wait state
>> (command - read - read - result).
>>
>>
>>
> I do not like the concept of telling the master at the beginning of each
> cycle what the latency will be.
> But I believe that you get what you want simply by using split
> transactions.
> The slave acknowledges that it latched the address and control
> information and the master is free to
> supply the next address to the next or the same slave.
> Pipelining within a single slave can have any amount of levels. The
> slave just keeps acknowleding addresses
> and after a while starts acknowleding data.
> Having multiple outstanding read transactions to different slaves is
> tricky and probably not worth the effort.
> I would suggest limiting the bus to one or none outstanding transaction
> to other slaves. Otherwise it would be
> necessary to keep a queue of outstanding slaves and select the right
> data source at the right time.
>
> Unfortunately I am not available at the moment to implement any
> hardware. To many outstanding transactions ;-)
>
> Kolja >
>
> ________________________________________________________________________
> ________________________________________________________________________ > To post a message, send it to: fpga-cpu@fpga...
> To unsubscribe, send a blank message to: fpga-cpu-unsubscribe@fpga...
> ------------------------------------------------------------------------
> Yahoo! Groups Links >
>
> ------------------------------------------------------------------------ >
>
> ---------------------------------
> Yahoo! Music Unlimited - Access over 1 million songs. Try it free.
>
> [Non-text portions of this message have been removed] > To post a message, send it to: fpga-cpu@fpga...
> To unsubscribe, send a blank message to: fpga-cpu-unsubscribe@fpga...
> Yahoo! Groups Links
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )