Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
correction-
>From the help system, the AHDL definition for a dual-clock fifo is:
FUNCTION lpm_fifo_dc (data[], rdreq, wrreq, rdclock, wrclock, aclr)
WITH (LPM_WIDTH, LPM_NUMWORDS,...)
RETURNS (q[], rdempty, rdfull, wrempty, wrfull,...);
INPUTS:
data[]: Input port LPM_WIDTH wide.
rdclock: Positive-edge-triggered Clock. Synchronous read of lpm_fifo_dc.
wrclock: Positive-edge-triggered Clock. Synchronous load of lpm_fifo_dc.
I assume only one edge of the clock is needed, rather than a series of
pulses that 'clock' implies?
wrreq: Write request control. The data[] port is written to the
lpm_fifo_dc. Writing is disabled if wrfull = 1.
rdreq: Read request control. The oldest data in the lpm_fifo_dc goes
to the q[] port. Reading is disabled if rdempty = 1.
Why is wrreq and rdreq needed when there are separate input and
output ports? Are they just to switch an internal bus mux or
something?
aclr: Asynchronous Clear input. Resets the lpm_fifo_dc to empty.
OUTPUTS:
q[]: Output port LPM_WIDTH wide.
rdempty: If asserted, indicates that the lpm_fifo_dc is empty and
disables the rdreq port. Synchronized with rdclock.
wrfull: If asserted, indicates that the lpm_fifo_dc is full and
disables the wrreq port. Synchronized with wrclock.
wrempty: Indicates that the lpm_fifo_dc is empty. Delayed version of
rdempty that is synchronized with wrclock.
rdfull: If asserted, indicates that the lpm_fifo_dc is full. Delayed
version of wrfull that is synchronized with rdclock.
Peter Alfke wrote:
>
> What's you definition of a clock?
> Any asynchronous FIFO obviously needs one signal that "clocks" data in,
> and another one that "clocks" data out, with the appropriate handshake
> interfaces.
> So the only question is:
> are these clocks free-running and use clock enable for control ( which
> makes the design easier)
> or is there just one edge per transfer ( makes the design more tricky).
>
> Peter Alfke, Xilinx Applications
> =================================
> Russell Shaw wrote:
>
> > Hi,
> >
> > I've been using a cypress async. fifo chip, and tried to do the same
> > thing in maxplus2. However, the lpm functions only have fifos that
> > require clocks. The fifo chip i was using didn't need *any* clocks.
> > Will i need to do my own?
--
___ ___
/ /\ / /\
/ /__\ / /\/\
/__/ / Russell Shaw, B.Eng, M.Eng(Research) /__/\/\/
\ \ / Victoria, Australia, Down-Under \ \/\/
\__\/ \__\/
Article: 31976An asynchronous FIFO is a black box where you clock data into the device on one port, and you clock data out of it on the other port, at any time, in thesame order as the input. The internal operation is "none of your business" , it's magically all done for you. That's what makes FIFOs so neat. They quietly do their job and only complain when they are full or empty. Peter Alfke ========================= Russell Shaw wrote: > correction- > > >From the help system, the AHDL definition for a dual-clock fifo is: > > FUNCTION lpm_fifo_dc (data[], rdreq, wrreq, rdclock, wrclock, aclr) > WITH (LPM_WIDTH, LPM_NUMWORDS,...) > RETURNS (q[], rdempty, rdfull, wrempty, wrfull,...); > > INPUTS: > > data[]: Input port LPM_WIDTH wide. > > rdclock: Positive-edge-triggered Clock. Synchronous read of lpm_fifo_dc. > > wrclock: Positive-edge-triggered Clock. Synchronous load of lpm_fifo_dc. > > I assume only one edge of the clock is needed, rather than a series of > pulses that 'clock' implies? > > wrreq: Write request control. The data[] port is written to the > lpm_fifo_dc. Writing is disabled if wrfull = 1. > > rdreq: Read request control. The oldest data in the lpm_fifo_dc goes > to the q[] port. Reading is disabled if rdempty = 1. > > Why is wrreq and rdreq needed when there are separate input and > output ports? Are they just to switch an internal bus mux or > something? > > aclr: Asynchronous Clear input. Resets the lpm_fifo_dc to empty. > > OUTPUTS: > > q[]: Output port LPM_WIDTH wide. > > rdempty: If asserted, indicates that the lpm_fifo_dc is empty and > disables the rdreq port. Synchronized with rdclock. > > wrfull: If asserted, indicates that the lpm_fifo_dc is full and > disables the wrreq port. Synchronized with wrclock. > > wrempty: Indicates that the lpm_fifo_dc is empty. Delayed version of > rdempty that is synchronized with wrclock. > > rdfull: If asserted, indicates that the lpm_fifo_dc is full. Delayed > version of wrfull that is synchronized with rdclock. > > Peter Alfke wrote: > > > > What's you definition of a clock? > > Any asynchronous FIFO obviously needs one signal that "clocks" data in, > > and another one that "clocks" data out, with the appropriate handshake > > interfaces. > > So the only question is: > > are these clocks free-running and use clock enable for control ( which > > makes the design easier) > > or is there just one edge per transfer ( makes the design more tricky). > > > > Peter Alfke, Xilinx Applications > > ================================= > > Russell Shaw wrote: > > > > > Hi, > > > > > > I've been using a cypress async. fifo chip, and tried to do the same > > > thing in maxplus2. However, the lpm functions only have fifos that > > > require clocks. The fifo chip i was using didn't need *any* clocks. > > > Will i need to do my own? > > -- > ___ ___ > / /\ / /\ > / /__\ / /\/\ > /__/ / Russell Shaw, B.Eng, M.Eng(Research) /__/\/\/ > \ \ / Victoria, Australia, Down-Under \ \/\/ > \__\/ \__\/Article: 31977
To clock data in and out, you just need inclock, outclock, empty, full. Why then rdreq, wrreq? Peter Alfke wrote: > > An asynchronous FIFO is a black box where you clock data into the device on > one port, and you clock data out of it on the other port, at any time, in > thesame order as the input. > The internal operation is "none of your business" , it's magically all done > for you. > That's what makes FIFOs so neat. They quietly do their job and only complain > when they are full or empty. > > Peter Alfke > ========================= > Russell Shaw wrote: > > > correction- > > > > >From the help system, the AHDL definition for a dual-clock fifo is: > > > > FUNCTION lpm_fifo_dc (data[], rdreq, wrreq, rdclock, wrclock, aclr) > > WITH (LPM_WIDTH, LPM_NUMWORDS,...) > > RETURNS (q[], rdempty, rdfull, wrempty, wrfull,...); > > > > INPUTS: > > > > data[]: Input port LPM_WIDTH wide. > > > > rdclock: Positive-edge-triggered Clock. Synchronous read of lpm_fifo_dc. > > > > wrclock: Positive-edge-triggered Clock. Synchronous load of lpm_fifo_dc. > > > > I assume only one edge of the clock is needed, rather than a series of > > pulses that 'clock' implies? > > > > wrreq: Write request control. The data[] port is written to the > > lpm_fifo_dc. Writing is disabled if wrfull = 1. > > > > rdreq: Read request control. The oldest data in the lpm_fifo_dc goes > > to the q[] port. Reading is disabled if rdempty = 1. > > > > Why is wrreq and rdreq needed when there are separate input and > > output ports? Are they just to switch an internal bus mux or > > something? > > > > aclr: Asynchronous Clear input. Resets the lpm_fifo_dc to empty. > > > > OUTPUTS: > > > > q[]: Output port LPM_WIDTH wide. > > > > rdempty: If asserted, indicates that the lpm_fifo_dc is empty and > > disables the rdreq port. Synchronized with rdclock. > > > > wrfull: If asserted, indicates that the lpm_fifo_dc is full and > > disables the wrreq port. Synchronized with wrclock. > > > > wrempty: Indicates that the lpm_fifo_dc is empty. Delayed version of > > rdempty that is synchronized with wrclock. > > > > rdfull: If asserted, indicates that the lpm_fifo_dc is full. Delayed > > version of wrfull that is synchronized with rdclock. > > > > Peter Alfke wrote: > > > > > > What's you definition of a clock? > > > Any asynchronous FIFO obviously needs one signal that "clocks" data in, > > > and another one that "clocks" data out, with the appropriate handshake > > > interfaces. > > > So the only question is: > > > are these clocks free-running and use clock enable for control ( which > > > makes the design easier) > > > or is there just one edge per transfer ( makes the design more tricky). > > > > > > Peter Alfke, Xilinx Applications > > > ================================= > > > Russell Shaw wrote: > > > > > > > Hi, > > > > > > > > I've been using a cypress async. fifo chip, and tried to do the same > > > > thing in maxplus2. However, the lpm functions only have fifos that > > > > require clocks. The fifo chip i was using didn't need *any* clocks. > > > > Will i need to do my own? > > > > -- > > ___ ___ > > / /\ / /\ > > / /__\ / /\/\ > > /__/ / Russell Shaw, B.Eng, M.Eng(Research) /__/\/\/ > > \ \ / Victoria, Australia, Down-Under \ \/\/ > > \__\/ \__\/ -- ___ ___ / /\ / /\ / /__\ / /\/\ /__/ / Russell Shaw, B.Eng, M.Eng(Research) /__/\/\/ \ \ / Victoria, Australia, Down-Under \ \/\/ \__\/ \__\/Article: 31978
Many FPGA/ASIC designers (myself included) avoid gated clocks like the plague. The preferred alternative is what is commonly called the "clock enable". For the LPM_FIFO_DC (we're talkin' MAX+2 here), the rdreq and wrreq are the clock enables for the read clock and the write clock, respectively. In the case of the LPM_FIFO_DC, these inputs are not optional. If you prefer/insist on using gated clocks for read and write, then tie the rdreq and wrreq inputs to 'VCC'. Hope this helps, Russell! -- Bob Elkind, the e-team (fpga consulting, etc.) Russell Shaw wrote: > To clock data in and out, you just need inclock, outclock, empty, full. > Why then rdreq, wrreq? >Article: 31979
The Max7K family, in my experience, tends to be more finicky about being filled to >80% utilisation with pinouts pre-defined. The 6K and the Acex 1K families (my current favourites) are much more forgiving in this regard (and of course, they also have many more pins :=) ). You may wish to consider replacing your Max7Ks device with a Flex6Ka (3.3V) or Acex1K (3.3V/2.5V) with an EPC2 (in-system programmable config EEROM). You probably won't be very far removed in cost, and you will be light-years ahead in usable gates, power consumption, AC performance, and pinot flexibility. -- Bob Elkind, the e-team (fpga/asic design, consulting, etc.) Russell Shaw wrote: > Hi all, > > I fitted an AHDL design into a max7000s device, but some > pins had to be moved to make a fit. > > Is there a way to group pins in maxplus2 so that the fitter can move > the whole group without splitting it? (useful for buses) > > Also posted in: alteraFPGA@egroups.com (yahoo groups) > > -- > ___ ___ > / /\ / /\ > / /__\ / /\/\ > /__/ / Russell Shaw, B.Eng, M.Eng(Research) /__/\/\/ > \ \ / Victoria, Australia, Down-Under \ \/\/ > \__\/ \__\/Article: 31980
Russell, If you consider the Acex1K, an added consideration is that FIFOs (see your other thread re: async fifos) are implemented in on-board embedded RAM arrays rather than a sea of flip-flops (in the the Max7K series, for example). -- Bob bob elkind wrote: > You may wish to consider replacing your Max7Ks device with a > Flex6Ka (3.3V) or Acex1K (3.3V/2.5V) with an EPC2 (in-system > programmable config EEROM). You probably won't be very far > removed in cost, and you will be light-years ahead in usable gates, > power consumption, AC performance, and pinot flexibility. > > -- Bob Elkind, the e-team (fpga/asic design, consulting, etc.) >Article: 31981
There is a design for programming flash via a FOGA on my website: http://members.iinet.net.au/~daveb/tricks/fpga-ldr/loader.html It's for the rather old Xilinx XC4000 series, but shouldn't be too hard to convert. Magnus Homann <d0asta@mis.dtek.chalmers.se> wrote: :Kolja Sulimma <kolja@sulimma.de> writes: : :> > I'd think you could just use the boundary scan already in the fpga :> > :> > "all" you'd need is a program that via jtag can wiggle the fpga pins :> > connected to the flash and thus the pins on the flash in the rigth :> > sequence, I'm not sure how fast you can run the boundry scan so it :> > may be slow though :> > :> > -Lasse :> > -- Lasse Langwadt Christensen, :> > -- PHX,AZ :> :> The last FLASH Datasheet that I saw said something about 9us programming time per :> byte. :> You should be able to match that with JTAG ;-) : :Flashes tend to be programmed in bulk mode, that is for instance 256 :bytes at a time. You through 256 bytes to the FLASH as fast as you :can, then start programming. : :Now, 9us, you say. If your JTAG is doing 10 MHz, that's only 90 :clocks. Considering that the larger (Xilinx) FPGAs have three boundary :scans per I/O, that can be a lot of clocks (say 700). If you are using :the internal JTAG chain, you need to go throuhg all of them. Then, if :you use byte-wide connection to the Flash, and need to strobe the :WR-signal, it takes _at least_ 1400 clocks to write one byte to the :Flash. With 10 MHz JTAG, that is about 140 us. : :Why, oh why, can't Intel make Flash with JTAG? : :HomannArticle: 31982
"Magnus Homann" <d0asta@mis.dtek.chalmers.se> wrote in message news:ltsnh9dztw.fsf@mis.dtek.chalmers.se... > "Austin Franklin" <austin@dar54kroom.com> writes: > > > > you're going to find that he or she > > > has more expectations of a FIFO than simply the ordering. In particular, > > > it is expected that a FIFO can contain a VARIABLE amount of data, from > > > zero items up to the FIFO depth. Your two flops with no logic always > > > contain a FIXED amount of data. > > > > No, that isn't true. That's YOUR limited understanding. > > > > This is REALLY a simple concept. I don't understand why you want to argue > > about this, except for the sake of arguing. You really don't know that FIFO > > simply means FIRST IN FIRST OUT, and anything that provides that function IS > > a FIFO? No matter what the implementation is? > > Oh, you mean like a piece of wire? Put in an electrical signal in one > end, and it will come out in the other, in the same roder. First in, > first out. > > Homann > -- > Magnus Homann, M.Sc. CS & E > d0asta@dtek.chalmers.se That is exactly right, you can stuff bits down the line and they always come out in the FIFO order. In fact, some of the earliest computers used that mechanism to implement their memories. They did not use a piece of wire, they just a column of mercury instead, but the principle is similar, just a delay line. If you introduce soliton pulses of electrons down your length of wire, you have a FIFO. HannuArticle: 31983
Austin Franklin wrote: > > Now I very > > seldom have a problem getting what I want even in very highly optimized > > design. > > How do you know? Do you go in and check with FPGA editor? I don't hollar until I am hurt. My real issues are speed and density. So if my circuit is snall enough and fast enough, I don't worry about it. But when I have timing or size issues I look for the cause. More often than poor synthesis by the complier, I find that the timing tools are not doing what I want. When I find a complier not giving me what I want, I tune the HDL if possible. It is very seldom that I need to instantiate objects other than RAM/ROM. > What has happened is now that the parts are so much faster, just like the > x86 CPUs, one can get design implementations that are not very optimal, but > meet timing. The parts are also so much larger, so taking up more resources > using HDLs to implement a function, isn't such a big deal. That is exactly right most of the time. There is also the trade off of how much time to work the design vs. how much you really want to squeeze out of the design. Just like software, we are getting to a point where the cost of the gates is not as important as the cost of programming them. > What I would like to see is the tool vendors provide a document that shows > how the constructs are disseminated. It should be deterministic, and the > designer needs to know, without having to play games, or worry between > revisions of the same tool, how the tools behave. The key is consistency. I have not seen a lot of changes in the more recent tools. But I have not been looking for them either. It is likely that unless the results vary dramtically, I would not see small differences. > The other issue, that has been partially solved, is placement issues. Being > able to consistently name an instance, and floorplan it. I still see issues here. My current design requires that we identify nodes for timing constraints using the backend tool. We can pick them out interactively using general names from the hdl heirarchy. But the signal/instance names put in the file are for specific items. Seemingly based on the phase of the moon, the synthesis tool will output somewhat different structures which require us to repeat the interactive step each time. I suspect this is due to some of the optimizations the synthesis tool does. I have seen signals internal to a module being shared with other modules since they both generated the signal in the same way. So if one of the modules is changed, it can affect the name of a signal in another module. This is a little bit of a problem, but I see this as more of a problem with the timing tool. I should not have to use an interactive tool to identify the timing points. I should be able to use my general, source oriented names in the timing constraints file. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 31984
Falk Brunner wrote: > > Austin Franklin schrieb: > > > > > > So jump in and get to know HDLs. You may even like it once you learn the > > > > flow. > > > > > > 100% ACK. I take that "ACK" is as in Bill the cat, "ACK!" and a bad thing? > > Actually, I find the best design flow to use schematics for the data paths > > (since that's what typically gets floorplanned the most), and HDL for the > > random logic and state machines. When the HDLs don't make timing, or are to > > obese, I then convert them to schematics. > > Hmm. I think we all agree that the designer needs a block diagram on > paper/document for documentation AND in his head. Schematics naturally > supports this block diagramms for free. I dont use schematics, just use > a generic tool to draw the block diagramm of my circuit, the details are > covered with comments in the VHDL code. I don't agree that schematics substitute for a block diagram. They are often so full of details that you can't see the flow for the gates! Using heirarchical schematics start causing some of the same problems that HDLs have. The signal names get complicated by the heirarchy path and even renamed as one wire that traverses several levels will have several names. The back end tool will want to pick just one name for the whole net, but which one? I use block diagrams and module prototypes for initial design and a start for post design documentation. I think schematics would be way too much detail for either of these purposes. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 31985
I wrote: Why not just compile the source files that come with Foundation? That way Coregen & the libs will match up. Apologies, I should have RTFS. It appears that for WebPACK3.2 at least the Verilog simprims src dir is missing all the models needed for Spartan2 & VirtexE. It only seems to have the CPLD stuff.Article: 31986
Hi, I read the data for the Acex1K and found it to be great:) However, maxplus2 kept crashing at the fitter stage. After reading some fine-print, i upgraded my pc from 64MB to 256MB, and am about to try again (after 6+ hours of poking at the main-board trying to make it work again, i think it was the cpu socket...) bob elkind wrote: > > Russell, > > If you consider the Acex1K, an added consideration is that > FIFOs (see your other thread re: async fifos) are implemented > in on-board embedded RAM arrays rather than a sea of > flip-flops (in the the Max7K series, for example). > > -- Bob > > bob elkind wrote: > > > You may wish to consider replacing your Max7Ks device with a > > Flex6Ka (3.3V) or Acex1K (3.3V/2.5V) with an EPC2 (in-system > > programmable config EEROM). You probably won't be very far > > removed in cost, and you will be light-years ahead in usable gates, > > power consumption, AC performance, and pinot flexibility. > > > > -- Bob Elkind, the e-team (fpga/asic design, consulting, etc.) > > -- ___ ___ / /\ / /\ / /__\ / /\/\ /__/ / Russell Shaw, B.Eng, M.Eng(Research) /__/\/\/ \ \ / Victoria, Australia, Down-Under \ \/\/ \__\/ \__\/Article: 31987
Hi, What other signal gates the clock in a 'gated clock' design? For LPM_FIFO_DC, to write data, is this correct: 1) Apply data to input port 2) Assert wrreq if not full 3) Apply a low-to-high edge at wrclock How much delay should there be between 2 and 3? A small delay? or whole clock cycles? bob elkind wrote: > > Many FPGA/ASIC designers (myself included) avoid gated clocks like the plague. > The preferred alternative is what is commonly called the "clock enable". > > For the LPM_FIFO_DC (we're talkin' MAX+2 here), the rdreq and wrreq are the > clock enables for the read clock and the write clock, respectively. In the case > of the LPM_FIFO_DC, these inputs are not optional. If you prefer/insist on using > gated clocks for read and write, then tie the rdreq and wrreq inputs to 'VCC'. > > Hope this helps, Russell! > > -- Bob Elkind, the e-team (fpga consulting, etc.) > > Russell Shaw wrote: > > > To clock data in and out, you just need inclock, outclock, empty, full. > > Why then rdreq, wrreq? > > -- ___ ___ / /\ / /\ / /__\ / /\/\ /__/ / Russell Shaw, B.Eng, M.Eng(Research) /__/\/\/ \ \ / Victoria, Australia, Down-Under \ \/\/ \__\/ \__\/Article: 31988
Magnus Homann wrote: > > Kolja Sulimma <kolja@sulimma.de> writes: > > > > I'd think you could just use the boundary scan already in the fpga > > > > > > "all" you'd need is a program that via jtag can wiggle the fpga pins > > > connected to the flash and thus the pins on the flash in the rigth > > > sequence, I'm not sure how fast you can run the boundry scan so it > > > may be slow though > > > > > > -Lasse > > > -- Lasse Langwadt Christensen, > > > -- PHX,AZ > > > > The last FLASH Datasheet that I saw said something about 9us programming time per > > byte. > > You should be able to match that with JTAG ;-) > > Flashes tend to be programmed in bulk mode, that is for instance 256 > bytes at a time. You through 256 bytes to the FLASH as fast as you > can, then start programming. > I think it's mostly eeproms that can do that, the flash I've used is programmed byte by byte > Now, 9us, you say. If your JTAG is doing 10 MHz, that's only 90 > clocks. Considering that the larger (Xilinx) FPGAs have three boundary > scans per I/O, that can be a lot of clocks (say 700). If you are using > the internal JTAG chain, you need to go throuhg all of them. Then, if > you use byte-wide connection to the Flash, and need to strobe the > WR-signal, it takes _at least_ 1400 clocks to write one byte to the > Flash. With 10 MHz JTAG, that is about 140 us. yep, and it'll normally need an extra write or two per byte to setup the write > > Why, oh why, can't Intel make Flash with JTAG? > I guess they think it's not needed, I guess in most applications flash is connected to a CPU or something and and all the stuff you'd normally use jtag for can be done from that end. -Lasse -- Lasse Langwadt Christensen, -- A Dane in Phoenix, ArizonaArticle: 31989
Rick Filipkiewicz wrote: > > Magnus Homann wrote: > > > Why, oh why, can't Intel make Flash with JTAG? > > > > Homann > > -- > > Magnus Homann, M.Sc. CS & E > > d0asta@dtek.chalmers.se > > Or anybody else for that matter. If you had a cheap slow JTAG Flash + an XC95K part you > could create an FPGA ``serial'' PROM for an awful lot less than the price of an > XC18VXX. if you have a flash and a cpld you could use the boundary scan, the cpld will probably have less pins than the fpga and it could thus be done faster, or you could put a jtag controller for the flash in the cpld, either permanently or reconfigure it when you need to update the flash -Lasse -- Lasse Langwadt Christensen, -- A Dane in Phoenix, ArizonaArticle: 31990
Russell Shaw wrote: > > Hi, > > What other signal gates the clock in a 'gated clock' design? > > For LPM_FIFO_DC, to write data, is this correct: > > 1) Apply data to input port > 2) Assert wrreq if not full > 3) Apply a low-to-high edge at wrclock > > How much delay should there be between 2 and 3? A small delay? or whole > clock cycles? > I'd say that you should either; Have wrreq always asserted and apply a posedge on wrclk when you want to write or do it the nice way have wrrclk continously running an assert wrreq for one clk cycle when you want to write -Lasse > bob elkind wrote: > > > > Many FPGA/ASIC designers (myself included) avoid gated clocks like the plague. > > The preferred alternative is what is commonly called the "clock enable". > > > > For the LPM_FIFO_DC (we're talkin' MAX+2 here), the rdreq and wrreq are the > > clock enables for the read clock and the write clock, respectively. In the case > > of the LPM_FIFO_DC, these inputs are not optional. If you prefer/insist on using > > gated clocks for read and write, then tie the rdreq and wrreq inputs to 'VCC'. > > > > Hope this helps, Russell! > > > > -- Bob Elkind, the e-team (fpga consulting, etc.) > > > > Russell Shaw wrote: > > > > > To clock data in and out, you just need inclock, outclock, empty, full. > > > Why then rdreq, wrreq? > > > > > -- > ___ ___ > / /\ / /\ > / /__\ / /\/\ > /__/ / Russell Shaw, B.Eng, M.Eng(Research) /__/\/\/ > \ \ / Victoria, Australia, Down-Under \ \/\/ > \__\/ \__\/ -- Lasse Langwadt Christensen, -- A Dane in Phoenix, ArizonaArticle: 31991
Hi, I have reverse engineered the Digilab kit with the Spartan XL on it... does not look like the normal Parallel schematic. Anyway, my basic question is firstly, what is the difference between CPLD and FPGA, and secondly, since I have the XCS10XL FPGA, must I only use the FPGA header on the parallel cable? If so, can I still use the JTAG Programmer utility in the Xilinx Foundation series because as of yet I cannot get my FPGA to program. Otherwise, how do I do it? Thanks NewbieArticle: 31992
> > > > I'd think you could just use the boundary scan already in the fpga > > > > > > > > "all" you'd need is a program that via jtag can wiggle the fpga pins > > > > connected to the flash and thus the pins on the flash in the rigth > > > > sequence, I'm not sure how fast you can run the boundry scan so it > > > > may be slow though For mode speed, use JTAG to load a special FPGA configuration which can reload the Flash from commands over the JTAG wires.Article: 31993
"Andy Peters" <andy(@)exponentmedia(.)com> wrote: >Hmmm..Ashenden sez this is OK; so does ModelSim. I'm also a Xilinx WebPACK user. I also have a copy of that book. Ashenden says this is OK in _VHDL-93_, which ModelSim also supports. >So, what's wrong? Does XST support generates? The problem is that, as far as I can tell, XST only understands _VHDL-87_. Turning to p.645 of your copy of Ashenden, note that some syntax is underlined. Anything underlined is VHDL-93 only, and I haven't found any of it usable under XST. [Not quite true, you can bind ports to literal values in XST, but I think that is strictly a VHDL-93 extension.] >But the example in the docs does NOT have the BEGIN, and the synth >is happy if I remove it from my code. But I'm not happy, since I >have to modify my code to satisfy the quirks of a non-compliant tool. It annoys me too, but you can't really say it is a non-compliant tool just because it isn't compliant with the most recent version of the language. Archaic, yes, but not non-compliant. >OK, so the tools are FREE. What should I expect? Curiously, I understand that Xilinx also sell the XST stuff (certainly, a synthesis bug in the WebPACK XST I found was apparently also present in the pay-for package). Now, 1993 is quite a long time ago and I'm pretty surprised that XST apparently doesn't include most of the later extensions. However, if you take this limitation into account and re-read Ashenden with that in mind (in other words, ignore the huge tracts of useful stuff it turns out you can't actually use) then things fall into place fairly well. Actually, if you're using Ashenden as a reference I'm surprised you didn't hit the lack of direct instantiation in VHDL-87 and XST first, as he spends eight pages (136--144) on how that's the obvious way to do things before finally saying you can't do it at all in VHDL-87... >Xilinx: are you listening? I'd certainly be interested to know if they plan to do something about this, but given the size of the differences between VHDL-87 and -93, I don't imagine it will happen at all soon. -- IanArticle: 31994
Using the Quartus fitter in maxplus2 (for acex1k), it crashes at 28% when doing a simple 32x8 lpm fifo function and not much else (pc has 256MB ram). By setting the option not to use quartus, the compilation completes without error. Have you found the same bugginess? bob elkind wrote: > > The Max7K family, in my experience, tends to be more finicky about > being filled to >80% utilisation with pinouts pre-defined. The 6K and the > Acex 1K families (my current favourites) are much more forgiving in this > regard (and of course, they also have many more pins :=) ). > > You may wish to consider replacing your Max7Ks device with a > Flex6Ka (3.3V) or Acex1K (3.3V/2.5V) with an EPC2 (in-system > programmable config EEROM). You probably won't be very far > removed in cost, and you will be light-years ahead in usable gates, > power consumption, AC performance, and pinot flexibility. > > -- Bob Elkind, the e-team (fpga/asic design, consulting, etc.) > -- ___ ___ / /\ / /\ / /__\ / /\/\ /__/ / Russell Shaw, B.Eng, M.Eng(Research) /__/\/\/ \ \ / Victoria, Australia, Down-Under \ \/\/ \__\/ \__\/Article: 31996
Philip Freidin wrote: > On Sat, 9 Jun 2001 18:02:44 +0200, Sven Heithecker > <heithecker@ida.ing.tu-bs.de> wrote: >>- comparsion of the different FPGA types (how many gates, how many useable >>gates, available speed,...) > > Get data sheets from the various vendors. The number of available families > of device, and devices within families is very large, and direct > comparison can be difficult, as the marketting departments have warped > reality too many times. Yes, this is indeed the problem. So I hoped that somebody, perhaps some magazine, did a comparsion, and gives / sells it to interested people / companies. > You may also want to look at www.fpga-faq.com FAQ 0014 where the > two main FPGA vendors products are discussed. Thax for information ! -- Sven Heithecker IDA, Hans-Sommer-Str. 66 Technical University of Braunschweig 38106 Braunschweig Tel. +49-(0)531-391-3751(voice)/4587(fax) Germany http://www.ida.ing.tu-bs.de/~svenh heithecker@ida.ing.tu-bs.deArticle: 31997
> I don't agree that schematics substitute for a block diagram. They are > often so full of details that you can't see the flow for the gates! It all depends on how well you know how to use the tools! Obvioulsy, you're not a schematic guy ;-) You certainly shouldn't have many, if any at all, gates on your schematics, except at the lowest levels, or a random gate here and there...for simplicity of drawing... > Using heirarchical schematics start causing some of the same problems > that HDLs have. The signal names get complicated by the heirarchy path > and even renamed as one wire that traverses several levels will have > several names. The back end tool will want to pick just one name for the > whole net, but which one? This is not a problem. The names are deterministic, unlike HDLs, which are NOT deterministic. The signal names will be what ever is the topest level signal name is. If you name your heirarchical elements, then the signal name is very easy to follow.Article: 31998
Hi, I am a master's student at Michigan State University. I am trying to map the Pentium units onto the Teramac FPGA's. Is there some way to know the digital design of certain units of the Pentium (say the Intruction Decoder) in order to estimate how the functionality of the same can be implemented using Teramac's Look up tables. In other words how many bytes would the Instruction decoder and other units require? Would appreciate any tips! Thanks Harsha jagasia jagasiah@cse.msu.eduArticle: 31999
Hi, I am a master's student at Michigan State University. I am trying to map the Pentium units onto the Teramac FPGA's. Is there some way to know the digital design of certain units of the Pentium (say the Intruction Decoder) in order to estimate how the functionality of the same can de implemented using Teramac's Look up tables. In other words how many bytes would the Instruction decoder and other units require? Would appreciate any tips! Thanks Harsha jagasia jagasiah@cse.msu.edu
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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