Hi John,
> I'm comfortable with the cross-development environment. I've used
> VxWorks with 68000, PPC, & intel and RTEMS with PPC and intel.
> These were all modified gnu toolchains so the linux stuff feels familiar.
Then I don't think you'll have any trouble
with the TS-7300.
>> What have you done regarding FPGA development so far?
>
> Nothing.
Ok.
>> Are you programming in Verilog or VHDL?
>
> I started acquainting myself with VHDL but will probably work
> with the TS code which is verilog.
Both are fairly commonly used, so keep your options open.
I do all of my coding in VHDL, mainly as when I started,
the Altera tools support for Verilog was poor.
>> Have you tried to use Modelsim to simulate your project?
>
> Not yet. I downloaded it but have not worked with it yet. My plan is
> to wade through the 8 hr video from altera. Don't know if they discuss
> Modelsim in this or not.
In my opinion, Modelsim is critical to the overall use of HDLs
and FPGA design. The procedure I use is:
1) Write a model of the processor interface used to talk to
the FPGA. This is generally referred to as a bus functional
model (BFM).
2) Write a processor-to-FPGA bridge,
eg. ARM local bus on the EP9302 to Wishbone bridge
or, ARM local bus on the EP9302 to Avalon bridge
if I wanted to use Altera's components.
3) Write a model of the device I'm going to talk to.
4) Write a Wishbone/Avalong target interface to control the device
5) Simulate and debug until it appears to work
6) Download to the FPGA and test
Step (1) will take a couple of iterations to get correct, but
then you'll use it forever after for testing components on
that board. Once steps (1) to (5) are working, step (6) usually
'just works', or any problems are easily resolved by comparing
logic analyzer traces to your test bench, and then you realize
your model is not correct.
> One question I have asked myself is how to feed and display Modelsim
> data pertaining to just my piece of the design but maybe this is
> straightforward.
Its called a 'testbench', it consists of;
(1) simulation-only processor BFM
(2) your FPGA design
(3) simulation-only models
(4) simulation-only processor read/write cycles that access
registers in your design, just as your software would.
>> Do you have a reference document containing the requirements
>> of the serial protocol? Its pretty simple to code up custom
>> serial protocols ...
>
> Not yet. The spec is open and I have glanced at it briefly
> but I need to nail down the details. Briefly, the master
> maintains a constantly circulating token. The master makes
> requests by inserting a message along with the token and
> slaves must respond (or at least send a NACK if the request
> is not reasonable) within some time window. Slaves may
> also send unsolicited event-related messages if they are so
> configured. Seems like a fairly simple protocol. I will be
> implementing a single bit rate, 2.5Mb/s.
Sounds a bit like a USB bus.
Given that you have a working version of the controller,
you'd write your HDL to emulate a similar software interface
for the master.
Look at the algorithmic state machine figures in the references
I sent. They directly translate to HDL code, i.e., if-then
statements based on the triangles. Its a lot easier to map
this type of diagram into HDL than it is bubble diagrams,
as in an ASM chart, each of the 'else' paths is explicitly
shown.
Cheers,
Dave
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|