Newbie to FPGA

Providing your depth of vectors isn't too large you could do it this way. 
The standard PicoBlaze has a limited code space and you may need to look at 
extending it's capabilities by adding on some bits, maybe just a store 
blockram, if you need a larger depth of vectors. Personally I would be 
tempted just to use a preloaded blockram with a counter set to wrap around 
at an appropriate value but that method assumes you have the necessary 
vectors to start with.

John Adair
Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development 
Board.
http://www.enterpoint.co.uk


"anand" <writeanand@gmail.com> wrote in message 
news:1150734727.957006.204090@p79g2000cwp.googlegroups.com...
> How about a freely available PicoBlaze microcontroller? I assume you
> can probably write assembly code for the PicoBlaze and that in turn
> drives the stimulus to the chip.
>
> As for the collection/monitoring of outputs, I believe the Picoblaze
> can read from the FPGA output pins and either do print statements or
> populate its own registers for offline reading.
>
>
> Would this work?
>
>
>
> John Adair wrote:
>> One of the things you can do is to build a stimulus mechanism into your
>> design for both early testing both for simulation and for running in the
>> real chip. Just remember to write it to be synthesisable not testbench
>> style. Once you are confident it is probably working introduce your real
>> source and sort out any issues caused by it being different to your 
>> internal
>> stimulus mechanism. For instance dealing with real setup and hold on 
>> input
>> signals.
>>
>> John Adair
>> Enterpoint Ltd. - Home of Raggedstone1. The Low Cost Spartan-3 
>> Development
>> Board.
>> http://www.enterpoint.co.uk
>>
>>
>> "anand" <writeanand@gmail.com> wrote in message
>> news:1150684323.749607.70170@c74g2000cwc.googlegroups.com...
>> > >You wouldn't really run a stimulus file through it -- you'd need to 
>> > >use
>> >>(or generate) an appropriate stream to run in real life to wiggle the
>> >>inputs pins on your FPGA.
>> >
>> > Thanks Tim. So, if I had to test the application in real life, then I
>> > have to stimulate the input pins, correct? So, how do I go about
>> > testing on the FPGA as to whether the design actually works in real
>> > life (not in simulation)?  Assume I have a H.264 stream that I can use.
>> >
>> > So in the dev board kit they have flash memory, I guess I can probably
>> > load the flash memory with the stimulus stream. But question is, how do
>> > I make it wiggle the appropriate pins of the FPGA itself, and how do I
>> > collect the output to verify it?
>> >
>> >
>> >
>> > Tim Wescott wrote:
>> >> anand wrote:
>> >>
>> >> > Hi,
>> >> >
>> >> > I am a pre-si verification engineer looking to learn HW design,
>> >> > synthesis and P&R through FPGAs.  (I am already very comfortable 
>> >> > with
>> >> > Verilog, so that is not the issue, I really want to learn to
>> >> > "design+synthesize+P&R" as opposed to "code in verilog").
>> >> >
>> >> > Recently checked out Spartan dev kit, looks very affordable.
>> >> > Questions:
>> >> >
>> >> > Is this the best way to go (for a hobbyist)? I am willing to spend
>> >> > couple 100 $$ on dev kits etc. Ive already downloaded the ISE 
>> >> > Webpack
>> >> > and have full access to Modelsim at work.
>> >>
>> >> Probably as good as any.
>> >> >
>> >> > What books should I get for DESIGN & SYNTHESIS (again, not verilog
>> >> > coding but "designing" synthesizable code with Verilog). Please 
>> >> > suggest
>> >> > books with and without an FPGA "tilt" or focus if possible.
>> >> >
>> >> I use Thomas & Moorby's "The Verilog Hardware Description Language",
>> >> which is mostly about Verilog but sprinkles in guidance for
>> >> synthesizable designs.
>> >> >
>> >> > Once you do everything and download stuff into the FPGA, how do you 
>> >> > run
>> >> > the application?
>> >>
>> >> You don't.  What's in an FPGA isn't an "application" and it doesn't
>> >> "run" in the sense that an application does.  Once you've _configured_
>> >> the FPGA you let it loose, and off it goes doing whatever you coded it
>> >> to do.
>> >>
>> >> > For ex, if you design a H.264 encoder (just for example), and the 
>> >> > FPGA
>> >> > already has the code downloaded after Synthesis and P&R stage, how 
>> >> > can
>> >> > I pass an example stimulus file (ie H.264 stream) to see if it works
>> >> > correctly?
>> >> >
>> >> You wouldn't really run a stimulus file through it -- you'd need to 
>> >> use
>> >> (or generate) an appropriate stream to run in real life to wiggle the
>> >> inputs pins on your FPGA.
>> >> >
>> >> > My grand vision is to build a H.264 encoder module in an FPGA, while
>> >> > teaching myself good design AND H.264 encoding in the process.
>> >> >
>> >> >
>> >> > Am I missing anything here? Anything else I should know?
>> >> >
>> >> > Thanks
>> >> >
>> >> You might want to start out a bit simpler -- I'd suggest blinking the
>> >> lights, then maybe blinking the lights under the control of the 
>> >> switches.
>> >>
>> >> --
>> >>
>> >> Tim Wescott
>> >> Wescott Design Services
>> >> http://www.wescottdesign.com
>> >>
>> >> Posting from Google?  See http://cfaj.freeshell.org/google/
>> >>
>> >> "Applied Control Theory for Embedded Systems" came out in April.
>> >> See details at http://www.wescottdesign.com/actfes/actfes.html
>> >
> 

Wouldn't it also be possible to use the parallel port of a PC to drive
the inputs of the FPGA and read back the output signals ? (Of course,
some TTL chips might be necessary in addition to that) The PC would
also drive the clock of the FPGA in order to "slow down" the circuit.

frankgerlach@gmail.com schrieb:
> Wouldn't it also be possible to use the parallel port of a PC to drive
> the inputs of the FPGA and read back the output signals ? (Of course,
> some TTL chips might be necessary in addition to that) The PC would
> also drive the clock of the FPGA in order to "slow down" the circuit.

This is possible but not very usefull. A clean simulation is much easier 
and much more usefull. So learn it the right way from the beginning on. 
No need to reinvent the wheel.

Regards
Falk