1994 Jul Aug Sep Oct Nov Dec 1994 1995 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1995 1996 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1996 1997 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1997 1998 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1998 1999 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1999 2000 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2000 2001 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2001 2002 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2002 2003 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2003 2004 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2004 2005 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2005 2006 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2006 2007 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2007 2008 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2008 2009 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2009 2010 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2010 2011 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2011 2012 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2012 2013 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2013 2014 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2014 2015 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2015 2016 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2016 2017 Jan Feb Mar Apr 2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

# Messages from 18850

Article: 18850
Subject: Re: Not complett multipier LUT in FPGA
From: Ray Andraka <randraka@ids.net>
Date: Thu, 18 Nov 1999 19:47:02 -0500
Links: << >>  << T >>  << A >>
You want a limited set multiplier.  Look at the multiplier page (
http://users.ids.net/~randraka/multipli.htm ) on my website, it tells you what
you need to know for the construction.  It will be up to you to translate that
to VHDL.  If you describe it at the circuit level, the translation is pretty
easy.

Bonio Lopez wrote:

> Sorry, I must correct small error in my first message(I have not typed
> word multiply):
> ....
> I want to paralell  MULTIPLY  (in FPGA) only this 5 integers with
> only...
>
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
> The fastest and easiest way to search and participate in Usenet - Free!

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 18851
Subject: Re: Need advice on interfacing SDRAM modules
From: Ray Andraka <randraka@ids.net>
Date: Thu, 18 Nov 1999 19:51:39 -0500
Links: << >>  << T >>  << A >>
Be careful clocking SDRAMs slow.  Some of the DDR SDRAMs have minimum clock
period specs which must be met to prevent data loss, and 33MHz is below that
spec for some parts.

Andy Peters wrote:

> You also need to remember that even though your read and write duty cycles
> may be very low, you must still talk to the SDRAM module at the clock speed.
> However, there's no law saying that you must run PC100 modules at 100 MHz.
> You can run them at 33 MHz if you like.
>
> You're asking about the SDRAM timing parameters.  You must understand them
> in order to use SDRAMs.  Parameter #1, of course, is the clock frequency,
> which should be obvious.  Parameter #2 is the "CAS latency" (also called
> read latency).  This is the delay between registration of the READ command
> and the availability of first data word.  It's usually two or three clock
> cycles, depending on the clock speed (a higher clock speed may require an
> extra clock cycle).  There's also a latency from the time you activate
> (OPEN) a row to the time you are allowed to assert a command; sometimes it's
> one tick, or two if the clock speed is fast.
>
> You should check out the SDRAM data sheets at Micron's web site.  They're
> large (50 pages) but you really need to understand how the parts work before
> attempting a design with them.  They're not necessarily difficult, just
> idiosyncratic.
>
> a
>
> --
> -----------------------------------------
> Andy Peters
> Sr Electrical Engineer
> National Optical Astronomy Observatories
> 950 N Cherry Ave
> Tucson, AZ 85719
> apeters (at) noao \dot\ edu
>
> "Creation Science" is oxymoronic.

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 18852
Subject: Re: implementing TCP/IP on PLD
From: Jamie Lokier <spamfilter.nov1999@tantalophile.demon.co.uk>
Date: 19 Nov 1999 02:43:30 +0100
Links: << >>  << T >>  << A >>
glen herrmannsfeldt writes:
> Well, say you implement a simple processor, either existing or new,
> on the FPGA and then write code for it.  Maybe even a C compiler and
> compile an existing implementation.  Much easier if it is just UDP, but
> if the code is in ROM or RAM then even TCP shouldn't be hard.

I worked for a while on a TCP implementation without using a processor.
Unfinished, just enough to do ARP and some header parsing.

I have been told of a small HTTP server on an FPGA.  I don't know if
they built a processor or not, and I will try to find references.
Curiously people don't seem to want to talk..

-- Jamie

Article: 18853
Subject: HDL coders wanted
Date: Fri, 19 Nov 1999 03:08:08 +0100
Links: << >>  << T >>  << A >>
Hello,

are you a Hardware Engineer? An EE student? Are you a VHDL/Verilog HDL
coder? Are you bored with your day-to-day job? Then help us with our open IP
cores projects. We are trying to design and build several different cores,
from microprocessors to various peripherals. All cores will be published at
http://www.opencores.org.

Visit us at http://www.opencores.org.

regards,
opencores.org team


Article: 18854
Subject: Re: How to use GSR-net in Virtex?
From: "Austin Franklin" <austin@dark88room.com>
Date: 19 Nov 1999 03:48:40 GMT
Links: << >>  << T >>  << A >>


Andy Peters <apeters.Nospam@nospam.noao.edu.nospam> wrote in article
<81197a$12u4$1@noao.edu>...
> Austin Franklin wrote in message <01bf318a$fc7c84d0$207079c0@drt1>...
> >
> >> Don't instantiate the startup block.  Just make sure that the reset
> >signal
> >> goes to EVERY SINGLE FLIP-FLOP IN YOUR DESIGN, and your synthesis tool
> >> should infer GSR.  If it does not, you should get a message saying
that
> >it
> >> was not inferred, and you'll have to look at the synthesis report to
see
> >> which flops were not included.
> >
> >That sounds tedious, probably un-necessary and may be even not right.
Why
> >not just do it this way:
> >
> >STARTUP_VIRTEX  startup_virtex (
> >        .GSR     (I_RESET),
> >        .GTS     (I_TS),
> >        .CLK     (1'b0)
> >         );
>
> No, neither tedious or unnecessary.  And it is right.  When I write code
> that's supposed to end up as a flipflop, I always include an async reset
> that uses the GSR.  That takes care of the power-on reset.  If a flip has
to
> be (re)set any time other than at power-up, I use a synchronous reset.

It shouldn't be any different to do reset 'correctly' for an HDL design or
a schematic design, so I will ignore any problems that may exist with using
HDLs.  This is an architecture issue, not a tool issue.

How can you say intentionally adding a reset to EVERY flop in the design is
not tedious?  Adding code to every instance of a flip flop in the design is
certainly extra work.

How is it necessary?  If the GSR resets every flop, and is on a global
dedicated net that doesn't even take up any resources (that can be used for
something else), and meets timing and operational requirements?

What are you talking about power on reset?  You don't have to do anything
for power on reset, it is inherent in the configuration process.  The data
sheet says (and I quote):

"The default Start-up sequence is that one CCLK cycle after DONE goes High,
the global tri-state signal (GTS) is released.  This permits the device
outputs to turn on as necessary.

One CCLK cycle later, the Global Set/Reset (GSR) and Global Write Enable
(GWE) signals are released.  This permits the internal storage elements to
begin changing state in response to the logic and the user clock."

It also goes on to say it may be paused until DLL lock has been achieved.

So, given this, I don't understand what or why it is you believe you have
to do special for power-on reset.

Now, on creating a 'special' net for use as a reset (instead of using the
inherent GSR).  The Virtex spec says the delay from GSR to XQ/YQ is under
10ns.  You say you assert your RESET to the part synchronously, so as long
as your clock frequency is not > 100MHz, you will not have any problems
using the dedicated global reset, and therefore, is unnecessary to do it
using non-dedicated resources in this regard.

The delay from SR to XQ/YQ is 1.1.  Using one of the secondary global nets
(you can't use a primary, they only go to clock pins) the delay from the
pad to the SR seems to easily be as high as the dedicated GSR routing,
depending on how far from the input buffer.  I only had around 64 flops in
the design, and they were not very far away, and I saw delays as high as
6+ns, and it burns a LOT of resources.  So, with a VERY small design, I am
seeing a delay using a secondary global net of 7.2ns.  I had a MAXDELAY and
a MAXSKEW on the RESET net.  So, in some instances is MAY be faster, then
again, not, but will only give you any benefit if you are running over
100MHz.

If you have an asynchronous reset, then all bets are off with either
method, no matter how low your RESET delay and/or skew is inside your part,
you stand a chance of having some of the chip come out of RESET on a
different clock edge...so you have to design accordingly, which is not too
tough to do, but still does not warrant not using the GSR.

So, it would also appear that using anything aside from the dedicated GSR
would not give you any benefit (except under very specific conditions), and
therefore, at least for my designs, unnecessary.  And given the extra
resources it would use, I would also call it 'wrong'.

I would appreciate it if you would post some 'facts' as to WHY creating
your own RESET signal, instead of using the dedicated GSR RESET signal, is
somehow beneficial.


Article: 18855
Subject: Re: How to use GSR-net in Virtex?
From: murray@pa.dec.com (Hal Murray)
Date: 19 Nov 1999 04:42:56 GMT
Links: << >>  << T >>  << A >>

> On power-up the registers initial values are all defined by the configuration
> program.  GSR is indeed too slow for use in higher performance designs.
...

Speaking of GSR being slow, that brings up the whole Metastability mess
again.  This probably isn't statistically important since GSR doesn't
change very often.

Note that even if you have plenty of time, you can't use GSR to reset
the whole chip if you have two or more asynchronous clocks.  At
least you can't do it cleanly.  Even if you only have one clock,
you also have to make sure that the signal connected to GSR is
clocked by that clock rather than a junk IO from a microprocessor
that's running on a different clock.

--
These are my opinions, not necessarily my employers.

Article: 18856
Subject: Re: implementing TCP/IP on PLD
Date: Thu, 18 Nov 1999 22:23:11 -0800
Links: << >>  << T >>  << A >>
Jamie Lokier <spamfilter.nov1999@tantalophile.demon.co.uk> wrote in message
news:m2zowbs1bx.fsf@pcep-jamie.cern.ch...
> glen herrmannsfeldt writes:
> I worked for a while on a TCP implementation without using a processor.
> Unfinished, just enough to do ARP and some header parsing.
>
> I have been told of a small HTTP server on an FPGA.  I don't know if
> they built a processor or not, and I will try to find references.

But when do you start calling it a processor (or not...)?  A lot of good
sized state machines I've seen start to look an awful lot like a
microsequencer, and from there it's just a hop, skip, and a jump until you
decide you're just going to have "this ROM" (that just so happens to be a
RAM in an FPGA...) that stores microcode and could start to have your
"hardware TCP/IP implementation" compute Pi or crack DES in its spare
time...

If Wade Peterson is around, he can let us know how much of something like a
Virtex XCV400 his PIC-compatible core takes.  I bet it's something under
10%.


Article: 18857
Subject: [Q] End-goal: porting ISA design to PCI. Which PLD to learn?
From: Paul Oh <paul@moray.cs.columbia.edu>
Date: Fri, 19 Nov 1999 06:58:12 -0500
Links: << >>  << T >>  << A >>

Hi to all!

My end-goal is to port my ISA card design to PCI.  This ISA card is a
simple 8255-based I/O board.  It's details if you are interested are at
http://www.boondog.com - see the Tutorials link.

I have no PCI experience.  My impression is that one needs a FPGA or other
programmable logic device (PLD) for PCI interfacing.

I have no PLD experience but do know digital logic and digital system
design (I am mechanical engineer).

Xilinx and Altera sell affordable ($100 range) development kits and software (student versions). Q. For my stated end-goal which PLD should I begin my learning curve on? Q. Are on-line PCI tutorials (in relation to my end-goal or porting ISA designs to PCI) ? Much appreciated, Paul Oh  Article: 18858 Subject: Re: implementing TCP/IP on PLD From: Jamie Lokier <spamfilter.nov1999@tantalophile.demon.co.uk> Date: 19 Nov 1999 13:29:03 +0100 Links: << >> << T >> << A >> Joel Kolstad writes: >> I have been told of a small HTTP server on an FPGA. I don't know if >> they built a processor or not, and I will try to find references. > But when do you start calling it a processor (or not...)? Well it is a processor of course. It's not a CPU. I'd call it a CPU when you make a point of building a CPU and programming it (or the hardware compiler does that for you). > A lot of good sized state machines I've seen start to look an awful > lot like a microsequencer, and from there it's just a hop, skip, and a > jump until you decide you're just going to have "this ROM" (that just > so happens to be a RAM in an FPGA...) that stores microcode and could > start to have your "hardware TCP/IP implementation" compute Pi or > crack DES in its spare time... None of the network applications I've implemented on FPGAs could be easily changed to compute Pi or crack DES. And the unfinished TCP/IP thing did not have a program ROM/RAM. You could add a Pi computer or DES cracker running in parallel though... > If Wade Peterson is around, he can let us know how much of something like a > Virtex XCV400 his PIC-compatible core takes. I bet it's something under > 10%. I once implemented a stack CPU on an Altera 10K20 in <"300 gates". A pain to program, but you can make these things very small. -- Jamie  Article: 18859 Subject: Re: Need advice on interfacing SDRAM modules From: Rick Filipkiewicz <rick@algor.co.uk> Date: Fri, 19 Nov 1999 12:57:26 +0000 Links: << >> << T >> << A >>  Andy Peters wrote: > You should check out the SDRAM data sheets at Micron's web site. They're > large (50 pages) but you really need to understand how the parts work before > attempting a design with them. They're not necessarily difficult, just > idiosyncratic. On the same site Micron also have some nice Verilog & VHDL simulation models of their SDRAMs that might also help in understanding some of the more obscure timing parameters.  Article: 18860 Subject: Re: How to use multiple resets? From: eml@riverside-machines.com.NOSPAM Date: Fri, 19 Nov 1999 13:23:50 GMT Links: << >> << T >> << A >> On Thu, 18 Nov 1999 08:42:09 -0500, Ray Andraka <randraka@ids.net> wrote: > In an >FPGA, you want to try to do strategic resets rather than global resets to >leave routing open for other signals, and more importantly to keep from >dragging your maximum clock frequency down into the weeds. See my previous >post in this thread for more detail. Agreed, but it's often not so bad that you have to worry about this. If you're using a synth, then it will duplicate highly-loaded nets. Spectrum tends to produce fanouts of 30 or 40 by default, and in large synchronous reset nets I've seen maximum net delays of about 12ns on a Virtex-4. And if you're worried, of course, then you should constrain the reset to a secondary clock buffer, which will give much better performance and routing. Evan  Article: 18861 Subject: Re: How to use GSR-net in Virtex? From: eml@riverside-machines.com.NOSPAM Date: Fri, 19 Nov 1999 13:23:58 GMT Links: << >> << T >> << A >> On Thu, 18 Nov 1999 09:23:09 -0700, "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam> wrote: >No, neither tedious or unnecessary. And it is right. When I write code >that's supposed to end up as a flipflop, I always include an async reset >that uses the GSR. That takes care of the power-on reset. If a flip has to >be (re)set any time other than at power-up, I use a synchronous reset. Or power-on preset, of course - try doing that without an explicit GSR signal. I had an interesting problem recently. I generated a GSR signal combinatorially, calling it GSR_H, and connected it to the GSR pin on a STARTUP_VIRTEX, as well as using GSR_H explicitly in my code (my personal preference is to do both). The synth duplicated GSR_H, because of its high fanout, generating a number of GSR_H_* nets, each sourced by a LUT3. However, the mapper saw only GSR_H itself connected to the STARTUP_VIRTEX, and so it removed the explicit connections on GSR_H, but *not* the connections on the duplicated GSR_H_* nets. So I ended up with maybe 90% of the GSR net explicitly routed, as well as using the real GSR itself. It was easily fixed, but I only spotted it by accident in FPGA editor. Evan  Article: 18862 Subject: who to reset one-hot-fsm ? From: Matthias Fuchs <matthias.fuchs@esd.h.uunet.de> Date: Fri, 19 Nov 1999 14:39:28 +0100 Links: << >> << T >> << A >> Hi, the following problem occured: I wrote a fsm in vhdl (foundation software) and it works fine. The hardware, where the fpga in used in, does not offer a "real" reset signal. How can I bring my fsm into a specific reset state after booting the fpga ? Can StartUp help me ? Matthias  Article: 18863 Subject: Re: How to use GSR-net in Virtex? From: "Austin Franklin" <austin@dark88room.com> Date: 19 Nov 1999 13:44:03 GMT Links: << >> << T >> << A >>  > I had an interesting problem recently. I generated a GSR signal > combinatorially, calling it GSR_H, and connected it to the GSR pin on > a STARTUP_VIRTEX, as well as using GSR_H explicitly in my code (my > personal preference is to do both). Why? What do you think that buys you?  Article: 18864 Subject: Re: How to use multiple resets? From: Ray Andraka <randraka@ids.net> Date: Fri, 19 Nov 1999 08:54:26 -0500 Links: << >> << T >> << A >> 12 ns is all well and good, unless you have clock frequencies that are well above 100MHz as are a large majority of my recent designs. Virtex-4 is quite capable of system clock speeds in excess of 100 MHz with careful design. eml@riverside-machines.com.NOSPAM wrote: > On Thu, 18 Nov 1999 08:42:09 -0500, Ray Andraka <randraka@ids.net> > wrote: > > > In an > >FPGA, you want to try to do strategic resets rather than global resets to > >leave routing open for other signals, and more importantly to keep from > >dragging your maximum clock frequency down into the weeds. See my previous > >post in this thread for more detail. > > Agreed, but it's often not so bad that you have to worry about this. > If you're using a synth, then it will duplicate highly-loaded nets. > Spectrum tends to produce fanouts of 30 or 40 by default, and in large > synchronous reset nets I've seen maximum net delays of about 12ns on a > Virtex-4. And if you're worried, of course, then you should constrain > the reset to a secondary clock buffer, which will give much better > performance and routing. > > Evan -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randraka  Article: 18865 Subject: Re: How to use GSR-net in Virtex? From: Ray Andraka <randraka@ids.net> Date: Fri, 19 Nov 1999 09:06:39 -0500 Links: << >> << T >> << A >> With an HDL design there is no GSR signal that you can yank on to initialize simulation unless you put something in your code to get at it. With schematic simulation you have that nice little implied GSR signal you can pulse to reset everything at the beginning of simulation. The synthesis tools won't infer a global reset unless every ff shares the same reset, and rightfully so. The problem is that for HDL simulation, you need some way to get that GSR signal into the ff, it can't just be imagined in. Austin Franklin wrote: > Andy Peters <apeters.Nospam@nospam.noao.edu.nospam> wrote in article > <81197a$12u4$1@noao.edu>... > > Austin Franklin wrote in message <01bf318a$fc7c84d0$207079c0@drt1>... > > > > > >> Don't instantiate the startup block. Just make sure that the reset > > >signal > > >> goes to EVERY SINGLE FLIP-FLOP IN YOUR DESIGN, and your synthesis tool > > >> should infer GSR. If it does not, you should get a message saying > that > > >it > > >> was not inferred, and you'll have to look at the synthesis report to > see > > >> which flops were not included. > > > > > >That sounds tedious, probably un-necessary and may be even not right. > Why > > >not just do it this way: > > > > > >STARTUP_VIRTEX startup_virtex ( > > > .GSR (I_RESET), > > > .GTS (I_TS), > > > .CLK (1'b0) > > > ); > > > > No, neither tedious or unnecessary. And it is right. When I write code > > that's supposed to end up as a flipflop, I always include an async reset > > that uses the GSR. That takes care of the power-on reset. If a flip has > to > > be (re)set any time other than at power-up, I use a synchronous reset. > > It shouldn't be any different to do reset 'correctly' for an HDL design or > a schematic design, so I will ignore any problems that may exist with using > HDLs. This is an architecture issue, not a tool issue. > > How can you say intentionally adding a reset to EVERY flop in the design is > not tedious? Adding code to every instance of a flip flop in the design is > certainly extra work. > > How is it necessary? If the GSR resets every flop, and is on a global > dedicated net that doesn't even take up any resources (that can be used for > something else), and meets timing and operational requirements? > > What are you talking about power on reset? You don't have to do anything > for power on reset, it is inherent in the configuration process. The data > sheet says (and I quote): > > "The default Start-up sequence is that one CCLK cycle after DONE goes High, > the global tri-state signal (GTS) is released. This permits the device > outputs to turn on as necessary. > > One CCLK cycle later, the Global Set/Reset (GSR) and Global Write Enable > (GWE) signals are released. This permits the internal storage elements to > begin changing state in response to the logic and the user clock." > > It also goes on to say it may be paused until DLL lock has been achieved. > > So, given this, I don't understand what or why it is you believe you have > to do special for power-on reset. > > Now, on creating a 'special' net for use as a reset (instead of using the > inherent GSR). The Virtex spec says the delay from GSR to XQ/YQ is under > 10ns. You say you assert your RESET to the part synchronously, so as long > as your clock frequency is not > 100MHz, you will not have any problems > using the dedicated global reset, and therefore, is unnecessary to do it > using non-dedicated resources in this regard. > > The delay from SR to XQ/YQ is 1.1. Using one of the secondary global nets > (you can't use a primary, they only go to clock pins) the delay from the > pad to the SR seems to easily be as high as the dedicated GSR routing, > depending on how far from the input buffer. I only had around 64 flops in > the design, and they were not very far away, and I saw delays as high as > 6+ns, and it burns a LOT of resources. So, with a VERY small design, I am > seeing a delay using a secondary global net of 7.2ns. I had a MAXDELAY and > a MAXSKEW on the RESET net. So, in some instances is MAY be faster, then > again, not, but will only give you any benefit if you are running over > 100MHz. > > If you have an asynchronous reset, then all bets are off with either > method, no matter how low your RESET delay and/or skew is inside your part, > you stand a chance of having some of the chip come out of RESET on a > different clock edge...so you have to design accordingly, which is not too > tough to do, but still does not warrant not using the GSR. > > So, it would also appear that using anything aside from the dedicated GSR > would not give you any benefit (except under very specific conditions), and > therefore, at least for my designs, unnecessary. And given the extra > resources it would use, I would also call it 'wrong'. > > I would appreciate it if you would post some 'facts' as to WHY creating > your own RESET signal, instead of using the dedicated GSR RESET signal, is > somehow beneficial. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randraka  Article: 18866 Subject: Re: implementing TCP/IP on PLD From: Ray Andraka <randraka@ids.net> Date: Fri, 19 Nov 1999 09:15:53 -0500 Links: << >> << T >> << A >> I've put simple risc microcontrollers in FPGAs at times when a complex or ill-defined protocol needs to be done in the FPGA. I've got a simple harvard machine that has a register file with separate read/write pointers, an add/subtract accumulator, I/O and conditional branches on 16 conditions that takes up about 70 CLBs in a 4K part, and runs at better than 60 MHz in 4000XL-09 parts. It's kind of a cross between an RCA 1802 (anyone remember those things?) and a PIC. If I were trying to do a TCP stack, I'd probably use a variant of that. Jamie Lokier wrote: > Joel Kolstad writes: > >> I have been told of a small HTTP server on an FPGA. I don't know if > >> they built a processor or not, and I will try to find references. > > > But when do you start calling it a processor (or not...)? > > Well it is a processor of course. It's not a CPU. > > I'd call it a CPU when you make a point of building a CPU and > programming it (or the hardware compiler does that for you). > > > A lot of good sized state machines I've seen start to look an awful > > lot like a microsequencer, and from there it's just a hop, skip, and a > > jump until you decide you're just going to have "this ROM" (that just > > so happens to be a RAM in an FPGA...) that stores microcode and could > > start to have your "hardware TCP/IP implementation" compute Pi or > > crack DES in its spare time... > > None of the network applications I've implemented on FPGAs could be > easily changed to compute Pi or crack DES. And the unfinished TCP/IP > thing did not have a program ROM/RAM. You could add a Pi computer or > DES cracker running in parallel though... > > > If Wade Peterson is around, he can let us know how much of something like a > > Virtex XCV400 his PIC-compatible core takes. I bet it's something under > > 10%. > > I once implemented a stack CPU on an Altera 10K20 in <"300 gates". A > pain to program, but you can make these things very small. > > -- Jamie -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randraka  Article: 18867 Subject: Re: How to use GSR-net in Virtex? From: "Austin Franklin" <austin@dark99room.com> Date: 19 Nov 1999 15:11:09 GMT Links: << >> << T >> << A >> That sounds more like a 'shortcoming' in HDL tools that should have been addressed long ago. Is this 'shortcoming' true for all the major HDL tools (FPGAExpress, Synplicity and Leonardo to name a few) that if you instantiate a STARTUP block (example below), that this logic that is now in your design (if you ran it thru the tools, it would be in the FPGA place and routed output file), does not carry thru to simulation? Ray Andraka <randraka@ids.net> wrote in article <3835596E.6C68AACF@ids.net>... > With an HDL design there is no GSR signal that you can yank on to initialize > simulation unless you put something in your code to get at it. With schematic > simulation you have that nice little implied GSR signal you can pulse to reset > everything at the beginning of simulation. The synthesis tools won't infer a > global reset unless every ff shares the same reset, and rightfully so. The > problem is that for HDL simulation, you need some way to get that GSR signal > into the ff, it can't just be imagined in. > > > > Austin Franklin wrote: > > > Andy Peters <apeters.Nospam@nospam.noao.edu.nospam> wrote in article > > <81197a$12u4$1@noao.edu>... > > > Austin Franklin wrote in message <01bf318a$fc7c84d0$207079c0@drt1>... > > > > > > > >> Don't instantiate the startup block. Just make sure that the reset > > > >signal > > > >> goes to EVERY SINGLE FLIP-FLOP IN YOUR DESIGN, and your synthesis tool > > > >> should infer GSR. If it does not, you should get a message saying > > that > > > >it > > > >> was not inferred, and you'll have to look at the synthesis report to > > see > > > >> which flops were not included. > > > > > > > >That sounds tedious, probably un-necessary and may be even not right. > > Why > > > >not just do it this way: > > > > > > > >STARTUP_VIRTEX startup_virtex ( > > > > .GSR (I_RESET), > > > > .GTS (I_TS), > > > > .CLK (1'b0) > > > > ); > > > > > > No, neither tedious or unnecessary. And it is right. When I write code > > > that's supposed to end up as a flipflop, I always include an async reset > > > that uses the GSR. That takes care of the power-on reset. If a flip has > > to > > > be (re)set any time other than at power-up, I use a synchronous reset. > > > > It shouldn't be any different to do reset 'correctly' for an HDL design or > > a schematic design, so I will ignore any problems that may exist with using > > HDLs. This is an architecture issue, not a tool issue. > > > > How can you say intentionally adding a reset to EVERY flop in the design is > > not tedious? Adding code to every instance of a flip flop in the design is > > certainly extra work. > > > > How is it necessary? If the GSR resets every flop, and is on a global > > dedicated net that doesn't even take up any resources (that can be used for > > something else), and meets timing and operational requirements? > > > > What are you talking about power on reset? You don't have to do anything > > for power on reset, it is inherent in the configuration process. The data > > sheet says (and I quote): > > > > "The default Start-up sequence is that one CCLK cycle after DONE goes High, > > the global tri-state signal (GTS) is released. This permits the device > > outputs to turn on as necessary. > > > > One CCLK cycle later, the Global Set/Reset (GSR) and Global Write Enable > > (GWE) signals are released. This permits the internal storage elements to > > begin changing state in response to the logic and the user clock." > > > > It also goes on to say it may be paused until DLL lock has been achieved. > > > > So, given this, I don't understand what or why it is you believe you have > > to do special for power-on reset. > > > > Now, on creating a 'special' net for use as a reset (instead of using the > > inherent GSR). The Virtex spec says the delay from GSR to XQ/YQ is under > > 10ns. You say you assert your RESET to the part synchronously, so as long > > as your clock frequency is not > 100MHz, you will not have any problems > > using the dedicated global reset, and therefore, is unnecessary to do it > > using non-dedicated resources in this regard. > > > > The delay from SR to XQ/YQ is 1.1. Using one of the secondary global nets > > (you can't use a primary, they only go to clock pins) the delay from the > > pad to the SR seems to easily be as high as the dedicated GSR routing, > > depending on how far from the input buffer. I only had around 64 flops in > > the design, and they were not very far away, and I saw delays as high as > > 6+ns, and it burns a LOT of resources. So, with a VERY small design, I am > > seeing a delay using a secondary global net of 7.2ns. I had a MAXDELAY and > > a MAXSKEW on the RESET net. So, in some instances is MAY be faster, then > > again, not, but will only give you any benefit if you are running over > > 100MHz. > > > > If you have an asynchronous reset, then all bets are off with either > > method, no matter how low your RESET delay and/or skew is inside your part, > > you stand a chance of having some of the chip come out of RESET on a > > different clock edge...so you have to design accordingly, which is not too > > tough to do, but still does not warrant not using the GSR. > > > > So, it would also appear that using anything aside from the dedicated GSR > > would not give you any benefit (except under very specific conditions), and > > therefore, at least for my designs, unnecessary. And given the extra > > resources it would use, I would also call it 'wrong'. > > > > I would appreciate it if you would post some 'facts' as to WHY creating > > your own RESET signal, instead of using the dedicated GSR RESET signal, is > > somehow beneficial. > > > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email randraka@ids.net > http://users.ids.net/~randraka > > >  Article: 18868 Subject: Re: How to use multiple resets? From: "Austin Franklin" <austin@dark99room.com> Date: 19 Nov 1999 15:14:15 GMT Links: << >> << T >> << A >> > and in large > synchronous reset nets I've seen maximum net delays of about 12ns on a > Virtex-4. And if you're worried, of course, then you should constrain > the reset to a secondary clock buffer, which will give much better > performance and routing. Not from what I tested. I found the delays thru the secondary buffers to be upwards of 10, if they end up going all over the chip. This seems inane to have to use routing resources for use as a global reset, when there is already a dedicated global reset hard wired in the device, just to accommodate some shortcomings in some tools.  Article: 18869 Subject: Re: How to use GSR-net in Virtex? From: "Austin Franklin" <austin@dark99room.com> Date: 19 Nov 1999 15:21:42 GMT Links: << >> << T >> << A >> > GSR is indeed too slow for use in higher performance designs. A > better strategy for FPGAs (and I know this makes an ASIC designer's blood > curdle) is to reset only strategic flip-flops in the design, which basically > means you really only need to reset a flip-flop in any logic loops and the > outputs of your chip. Why not just treat GSR like any asynchronous reset? This requires you to add one or more additional RESET states to the start of state machines (or what ever logic you have that this can be effected by), so when flops come out of reset in different clock cycles, there is no ill effect. Then you get ALL the performance you want, since it is now not frequency dependant, except in the fact that you may have to add one or more extra states...  Article: 18870 Subject: Re: Programming Virtex device via JTAG From: Tom McLaughlin <tomm@arl.wustl.edu> Date: Fri, 19 Nov 1999 09:52:50 -0600 Links: << >> << T >> << A >> Well, I guess no one has done this??? I've read all the docs I can get my hands on and I think I'm doing everything right. However, the Xilinx doc says that INIT must have a pulldown to ground on it to be able to program the device through the JTAG TAP. The test board we have has a pullup to Vcc on INIT. Is this my problem??? The tools say that the bitstream loads, but the DONE led never goes off and the FPGA does not function. Any help would be appreciated. Tom > I have a development board from VCC that has a Virtex XCV300 onboard. > It can be configured through a flash PROM, a multilink cable, an > xchecker cable and a JTAG port. I am trying to configure it via the > JTAG port so we can learn how this works for our system. >  Article: 18871 Subject: Re: How many bits in an FPGA bitstream? From: Luis Yanes <melus@esi.us.spamno.es> Date: Fri, 19 Nov 1999 18:10:35 +0100 Links: << >> << T >> << A >> On Sat, 13 Nov 1999 09:17:00 GMT rbarris@quicksilver.com (Rob Barris) wrote: > > Say for a relatively low end part like a Xilinx XC4005 as seen in the >XESS board, just how many bits is the "bitstream" file that is loaded into >it for configuration? Hundreds, thousands, tens of thousands? > > Sorry if this is a really basic question. I'm exploring tying a >microcontroller to an FPGA, and I'm wondering how much space I need to >worry about dedicating to the config stream. It might change over the >life of the system so a fixed configuration EPROM isn't in the cards. I was just wondering if for the larger parts would worth to compress the bitstream, trading configuration file size by configuration speed, decompressing on the fly. The .bit files compress about 50% with zip or other archiver. 73's de Luis mail: melus@esi.us.es Ampr: eb7gwl.ampr.org http://www.esi.us.es/~melus/ <- Homebrewed Hardware Projects with PCBs  Article: 18872 Subject: ARM7TDMI compatible synthesisable Module available From: info@r-and-d.de Date: Fri, 19 Nov 1999 18:27:13 +0100 Links: << >> << T >> << A >> R&D Technology anounces the availability of it's ARM7TDMI compatible synthesiable Verilog module. For more information look at www.r-and-d.de  Article: 18873 Subject: Re: How to use GSR-net in Virtex? From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam> Date: Fri, 19 Nov 1999 10:54:47 -0700 Links: << >> << T >> << A >> Austin Franklin wrote in message <01bf3240$f071f880\$207079c0@drt1>...

>It shouldn't be any different to do reset 'correctly' for an HDL design or
>a schematic design, so I will ignore any problems that may exist with using
>HDLs.  This is an architecture issue, not a tool issue.

Well, you can instantiate the GSR if you like, or you can let the tool do it
for you.  Me?  I prefer to let the tool instantiate GSR.  Makes the code a
bit more portable, too, but that's a detail.

>How can you say intentionally adding a reset to EVERY flop in the design is
>not tedious?  Adding code to every instance of a flip flop in the design is
>certainly extra work.

Not, not really.  Writing:

flop : process (clk, reset)
begin
if reset = '1' then
blah <= '0';

is not too difficult.  In fact, emacs conveniently does it for me.  It also
has the major advantage of letting the simulation match the reality (i.e.,
at the beginning of time, all flops are reset), and I don't have to deal
with the xilinx simulation models.  My test benches assert that reset line
at the beginning of time, and never after that.  It's only for power-on
reset.

It might be more difficult (read: time-consuming, tedious) in a schematic to
have to connect the reset net to the async set/reset of every flop; placing
the startup symbol relieves you of that necessity.  Then again, you've gotta
hook up the clock signal to every flop.

>How is it necessary?  If the GSR resets every flop, and is on a global
>dedicated net that doesn't even take up any resources (that can be used for
>something else), and meets timing and operational requirements?

If you write the code as above, and make sure that all of the flops have an
async reset signal in the sensitivity list, any tool worth a damn at the end
of 1999 should infer GSR, which is what we want.  FPGA Express and
Synplicity do.  In fact, if you screw up and forget to reset one of the
flops, FPGA Express complains and says that it won't infer GSR.  So, of
course it's a PITA to go through the reports and find the flops that you
forgot to reset, but I usually find those sorts of mistakes in pre-synthesis
simulation.  There tends to be big Us or Xs and red lines in the wave window
until the flop is explicitly set or cleared.

>What are you talking about power on reset?  You don't have to do anything
>for power on reset, it is inherent in the configuration process.  The data
>sheet says (and I quote):

Yup, read it many times. I know that the startup sequence after powerup
asserts GSR and resets all of the flipflops that it's connected to.
However, for simulation convenience, it's nice to have a signal the test
bench can assert for power-on reset.

>Now, on creating a 'special' net for use as a reset (instead of using the
>inherent GSR).  The Virtex spec says the delay from GSR to XQ/YQ is under
>10ns.  You say you assert your RESET to the part synchronously, so as long
>as your clock frequency is not > 100MHz, you will not have any problems
>using the dedicated global reset, and therefore, is unnecessary to do it
>using non-dedicated resources in this regard.

Perhaps I wasn't clear.  By "synchronous reset," I meant something like a
counter's synchronous clear signal that is generated by some other logic.  I
don't mean that the sync reset is intended to reset the entire chip.

For instance,

count : process (clk, reset) is
begin
if reset = '1' then
counter <= 0;    -- reset asserted at beginning of time
elsif rising_edge(clk) then
if clear = '1' then
counter <= 0; -- sync "clear" asserted by other logic
elsif enable = '1' then
counter <= counter + 1
end if;
end if;
end process count;

Clearly, the counter's "clear" signal must meet timing, as does the "enable"
signal, and the counter itself.  Perhaps calling the "clear" signal a reset
is a misnomer, even though it's function is to reset a bunch of flipflops.

>If you have an asynchronous reset, then all bets are off with either
>method, no matter how low your RESET delay and/or skew is inside your part,
>you stand a chance of having some of the chip come out of RESET on a
>different clock edge...so you have to design accordingly, which is not too
>tough to do, but still does not warrant not using the GSR.

>
>So, it would also appear that using anything aside from the dedicated GSR
>would not give you any benefit (except under very specific conditions), and
>therefore, at least for my designs, unnecessary.  And given the extra
>resources it would use, I would also call it 'wrong'.

Again, my async (GSR) reset is only used at power-up; all other flops are
set or reset synchronously as required by the design.

>I would appreciate it if you would post some 'facts' as to WHY creating
>your own RESET signal, instead of using the dedicated GSR RESET signal, is
>somehow beneficial.

Facts are above, counselor.

--
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

"Creation Science" is oxymoronic.


Article: 18874
Subject: Re: Altera Files vho and sdo too big
From: "Edwin Grigorian" <edwin.grigorian@jpl.nasa.gov>
Date: Fri, 19 Nov 1999 11:02:03 -0800
Links: << >>  << T >>  << A >>
I have had similar sized '.vo' (verilog) and '.sdo' files with a 93% full
10K200E  (low IO count) and was able to successfully do post Place & Route
simulations with Modelsim.  Simulations do take quite some time to complete
if your testbench uses up many cycles.

Edwin Grigorian
JPL

Rick Filipkiewicz <rick@algor.co.uk> wrote in message
news:382AA865.C202FD66@algor.co.uk...
>
>
> giuseppe giachella wrote:
>
> > After placing and routing my design on an Altera Flex 10KA250, Maxplus2
> > created two output files .vho and .sdo in order to start
> > a postlayout simulation. These two files have a dimension of 16 MB
> > each. It is almost impossible for me to compile such a vhdl and load
> > an sdf file so big (I have tried using Modelsim and VSS).
> >
> > Is there anyone who succeeded in simulating files so big ?
> >
> > What should I expect if I migrate my design an a APEX or VIRTEX
> > (they contain much more gates than a Flex 10KA250) ?
> >
>
> One approach would be to use a perl script to split the postroute netlist
> into separate pieces and compile them seprately into a library.
> Alternatively if VHDL makes that difficult and you have the co-simulation
> version of ModelSim you could output the netlist in the more compact &
easy
> to split Verilog form.
>
> For my postlayout Virtex XCV300 simulation I get an 8MB Verilog
netlist+8MB
> SDF and ModelSim [5.3aPE] handles this with no problems, takes just under
2
> minutes to compile - 450MHz P-II + 512MBytes.
>
>