Re: Superscalar Out-of-Order Processor on an FPGA
- From: "JJ" <johnjakson@xxxxxxxxx>
- Date: 10 May 2006 10:58:24 -0700
Göran Bilski wrote:
JJ wrote:
Curiously how do you prototype the architecture, in cycle C, or go
straight to HDL simulation?
Anyway have fun
John Jakson
transputer guy
the details are at wotug.org if interested
I personally use paper and pen.
I draw the datapath functionality and think about how they will map into
Xilinx FPGA structures while drawing and designing.
I like to have large papers so I can draw timing diagrams on the same page.
Only when I have some design which I believe would be reasonable I start
to code.
When I think more about it then I realize that my most used design tool
is still the paper and pen.
Göran
Aha, I kinda do the opposite, draw lots of tiny fragments on the small
notepad sheets and code up the model in cycle C in a Verilog subset or
style. If I use larger sheets I am afraid I will have to redraw the
whole thing too many times to keep if looking perfect.
For awhile I even stooped to ascii graphics over .... background once
things are settling down at least they can be edited in small blocks
but some edits are torture, better for regular paths. I rediscovered
Canvas for Mac & Windows an excellent older 2d drawing tool but thats
all it can do, but far better than the OpenOffice drawing.
Cycle C tells me right away that the architecture does what its
supposed to possibly with millions of cycles of testing and analysis of
different approaches but it doesn't give me any warnings about critical
paths until its too late. The notepad drawings though layout the C code
fragments as TTL/Lut level schematics so I usually have an idea of all
path length. The cycle C and the Verilog though are layed out in the
same format and sometime I can't tell which is which, although one has
to be careful with assigns, in C they are sequential, in Verilog they
are not.
One nice aspect of the C approach is that parts of the cpu expressed in
cycle C also have a faster behavioural version that can be used by
other applications such as compiler or OS as if they were running on a
PC with that hardware feature available such as the MMU which in this
case does memory allocation and user level memory management. That
means software can be written for the target and executed on a PC model
of it even though the hardware design is incomplete.
I do recall my days at Inmos where the Transputer was all over very
large A1? sheets of paper and on the walls and floors at gate level,
and much of it before any gate level simulation decades before
synthesis. I wouldn't want to go back to that again.
John Jakson
transputer guy
.
- Follow-Ups:
- Re: Superscalar Out-of-Order Processor on an FPGA
- From: Stephen Craven
- Re: Superscalar Out-of-Order Processor on an FPGA
- References:
- Superscalar Out-of-Order Processor on an FPGA
- From: Luke
- Re: Superscalar Out-of-Order Processor on an FPGA
- From: JJ
- Re: Superscalar Out-of-Order Processor on an FPGA
- From: Luke
- Re: Superscalar Out-of-Order Processor on an FPGA
- From: Eric Smith
- Re: Superscalar Out-of-Order Processor on an FPGA
- From: Luke
- Re: Superscalar Out-of-Order Processor on an FPGA
- From: JJ
- Re: Superscalar Out-of-Order Processor on an FPGA
- From: Göran Bilski
- Superscalar Out-of-Order Processor on an FPGA
- Prev by Date: Re: 87C52 & 87C51 core
- Next by Date: Re: CoolRunner XPLA3 getting axed?
- Previous by thread: Re: Superscalar Out-of-Order Processor on an FPGA
- Next by thread: Re: Superscalar Out-of-Order Processor on an FPGA
- Index(es):
Relevant Pages
|
