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
Phil Short wrote: > > It seems to me that you want something that is impossible. On one hand, > you seem to want an explanation that is reduced to bite-sized slogans. On > the other hand, you want to argue with the simplified explanation, picking > on details that are to complicated to fit into one sentence. So which do > you want - a simple slogan, or a detailed, nuanced discussion? You can't > have both. You've had the first, and decided to argue with it. So you > must really want the second, in which case you should really take the time > to read what much more qualified persons have written about at length in > books and formal papers. No Phil, am not asking for "bite-sized slogans". I am asking for a simple explanation of how this technology works better. Is it really that complex that it can't be explained? > One obvious source of juice is the difference between the longest and > shortest combinatorial delays (i.e. flip-flop output delay plus routing > delays plus LUT delays plus flip-flop setupt time plus (perhaps) clock > skew). The clock period in a sync design is determined by the maximum > delay. However, the device still has to wait for an entire clock period > even during a cycle when all relevant combinatorial delays are much > less than the maximum. This would not be the case in an async design, > where the performance of a circuit over a period of time is more likely to > be a multiple of the average combinatorial delay rather than a multiple of > the maximum combinatorial delay. Yes, but I explained how in a real time system, this only moves the problem from the clock domain to the system domain. Your chip can run at faster speeds when it is cooler or just a faster chip (process) but that won't be of any value since you have to design your system to the worst case chip delay. If you are talking about the different paths within the chip, I still don't agree that there is a significant difference. Sync logic is balanced so that the different circuits have about the same delay so that the clock speed can be optimized. So there is not much waste between the separate circuits. Within a given circuit the async logic still has to wait for the logest delay since it has no way of knowing what speed the logic will run. Remember the async handshake is really a delayed clock and must be delayed more than the worst path through the combinatorial logic. > EMI reduction due to spreading the switching current spikes over time > comes for free in an async design, rather than required special clock > chips. Yes, this is one advantage that async circuits have. But it is certainly not enough to warrant the efforts required for async design. -- 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: 75276
>This is not at all "innate" in silicon. The chips just need to be >designed for a range of Vcc rather than optimized for the best Vcc as >FPGAs are. They don't have to be designed for multiple voltages. You can design them for the primary target and then characterize them (aka fill in the blanks in the data sheet) at other voltages. Might be an interesting market opportunity. Similar to what Xilinx is doing with only testing to meet a specific design. Just run the tests at a different voltage. (after figuring out how fast the chip should go so and making another set of speed files for the tools and ...) -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 75277
Phil Short wrote: > > On Sun, 31 Oct 2004 14:49:44 -0600, Hal Murray wrote: > > > > With an async system, I'd expect you could do the same sort > > of thing. Maybe use timers rather than a spin/poll loop to > > keep with the low-power philosophy. But now the problem is > > that you have to correct for temp, voltage, and process. > > Temp and voltage you can measure. You can probably measure > > process by running some calibration code. But you still have > > to add a fudge factor for the software. How important is the > > software uncertantity relative to the hardware uncertantity? > > It strikes me that the hardware vendor would characterize and bin the > devices in some way that would be meaningful, and provide design tools > that would aid in this manner. For a fixed-function device (e.g. UART or > fifo) the binning process at the semiconductor vendor would take care of > the speed issue in just the same manner as is done today (from the > viewpoint of someone incorporating the part in their design). For an > instruction-programmable part (i.e. CPU) this would also be the same as > for today (parts speed-graded by the manufacturor, user doesn't have any > meaningful way to compare parts). And who knows if there will ever be > async programmable logic parts, but if there is, again the manufacturor > speed-grades the parts and has to provide layout and (worst-case) static > timing tools to the designer (no more 'magic' than the current FPGA/CPLD > situation). Ok, I think we are closing the loop here. Doesn't this make it clear that when designing with an async part, you still have to allow for the worst case timing in your system design? Doesn't that eliminate any speed advantage async parts might have by running faster when they can? -- 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: 75278
On Mon, 01 Nov 2004 00:32:27 -0500, rickman wrote: > Phil Short wrote: >> > > No Phil, am not asking for "bite-sized slogans". I am asking for a > simple explanation of how this technology works better. Is it really > that complex that it can't be explained? > Yes, it is too complex to explain by someone who is not a professional writer over a channel with multiple-hour round-trip delays, no visual feedback and no decent way to draw diagrams to explain points. > >> One obvious source of juice is the difference between the longest and >> shortest combinatorial delays (i.e. flip-flop output delay plus routing >> delays plus LUT delays plus flip-flop setupt time plus (perhaps) clock >> skew). The clock period in a sync design is determined by the maximum >> delay. However, the device still has to wait for an entire clock period >> even during a cycle when all relevant combinatorial delays are much >> less than the maximum. This would not be the case in an async design, >> where the performance of a circuit over a period of time is more likely >> to be a multiple of the average combinatorial delay rather than a >> multiple of the maximum combinatorial delay. > > Yes, but I explained how in a real time system, this only moves the > problem from the clock domain to the system domain. Your chip can run > at faster speeds when it is cooler or just a faster chip (process) but > that won't be of any value since you have to design your system to the > worst case chip delay. > I wasn't talking about the system domain. You are correct in hinting that there are significant problems interfacing between sync and async chips, such that the literature suggests that most of the speed benefits of async design may be lost in this case. It seems that it would be better if everything in the system is async, rather than a mix. Just another problem in gaining more widespread acceptance. > If you are talking about the different paths within the chip, I still > don't agree that there is a significant difference. Sync logic is > balanced so that the different circuits have about the same delay so > that the clock speed can be optimized. So there is not much waste > between the separate circuits. Within a given circuit the async logic Every circuit that I have ever designed has had a lot of waste. This includes both microprocessor-based systems and FPGA designs. Ignoring large combinatorial arithmetic elements, the control logic alone has had a large amount of non-fixable variation in delay. In any given circuit there have been places where accidents (or deliberate) of state machine design allow the output of one register to be directly connected to the input of another register, and other places in the same logic block where there may be half a dozen or dozen layers of logic, with no way to allow signals in the latter path to take multiple clocks before they are needed. All of these _differences_ in delay can add up. > still has to wait for the logest delay since it has no way of knowing > what speed the logic will run. Remember the async handshake is really a > delayed clock and must be delayed more than the worst path through the > combinatorial logic. > In fact, there are some (all?) async methodologies where there are no flip-flops at all, the state information ends up being 'kept' in the delay elements. In any case, the absence of any sensible way to use async design methods with FPGAs has prevented me from taking the time to totally wrapping my head around the detailed design methods. They are so different from sync design methodologies that I suspect that you have misconceptions about how things would work in an async design, with no way for me to determine what these misconceptions are in these usenet interactions. It would be best if you were curious to know more about async design to go back to more fundamental sources than usenet. I personally am always very suspicious of condensed or regurgitated descriptions, and prefer to go back to the most basic readable source. Takes more time, but then I am better able to understand what the real situation is, and to separate urban legend from the facts. As you note in another post, this thread has gone on too long. Best, -- PhilArticle: 75279
rickman <spamgoeshere4@yahoo.com> wrote in message news:<4185154A.25EEDBE0@yahoo.com>... > Sidney Cadot wrote: > > > > I would like to keep the things that are different for each of the > > boards concentrated in my "memory mapped I/O" VHDL source, for which > > I have three versions - one for each board. > > > > However, since XST needs toplevel ports for all external ports, I am > > currently forced to have three different versions for two hierarchical > > levels of design above the "memmapped-io.vhdl" as well, namely my > > toplevel design (toplevel.vhdl) and the MMU (mmu.vhdl) that routes > > between the CPU and the RAM, ROM, and I/O apertures. The only reason I > > need three versions of my toplevel and mmu entities is that I must > > hook up some external pins into the mmapped_io entity. > > Maybe I am being a little dense today, but I still don't understand. If > your IO functions are the same why would you need different ports? What > is different between the boards that you can't just describe the > differences in the IO pin assigments in the UCF file? I failed to make that particularly clear (sorry). There are hardware differences, e.g. * The number of seven-segment displays 0/1/4 * The number of LEDs 4/8/8 * The number of push-buttons: 2/3/4 * The number of sliding switches: 0/4/8 * The availability of AD/DA's on the development board * The interface to memory residing on the memory board > Even if you don't use a port, don't you still need different top level files? I don't see why that would be necessary. > Instantiating the IO pads is a good idea. Unfortunately, it didn't work - apparently the IPAD components are not contained in the UNISIM library, and just instantiated implicitly. This rhymes with another tidbit I found in the IPAD docs (Library Guide): "For HDL, it is not necessary to use these elements in the design. They will be added automatically." > If that doesn't work nothing will. Why are you so sure? I still have some hope :) Regards, SidneyArticle: 75280
newman5382@aol.com (newman) wrote in message news:
> The Designer's Guide To VHDL 2'nd Edition
> Peter J. Ashenden
> Page 8
> "Using VHDL terminology, we call the module reg4 a design entity, and
> the inputs and outputs are ports. Figure 1-7 shows a VHDL description
> of the interface to the entity. This is an example of an entity
> declaration. It introduces a name for the entity and lists the input
> and output ports, specifying that they carry bit values ('0' or '1')
> into and out of the entity. From this we see that an entity
> declaration describes the external view of the entity."
> If one were to be able to snake a signal out, without mapping it thru
> a port, then the entity declaration would not describe the external
> view of the entity.
There are two answers to this: a philosophical one and a practical
one.
(1) Philosophical
The "external view" (VHDL wise) of my "mmapped_io" component is
basically that it acts like a RAM block, i.e., it has a data bus and
an address bus, and R/W control bits. The fact that these happen to do
some interesting things to hardware, should be of no concern to the
VHDL modules that instantiate an "mmapped_io" component, that's the
whole point of having memory mapped I/O.
My mmapped I/O defines a 4K aperture to hardware. My "RAM" components
describe a 4K aperture to RAM. At a higher level in my design, I
should be able to interchange them without any changes except for the
instantiated component name I think.
(2) Practical
Ashenden notwithstanding, the VHDL program shown below demonstrates
that XST can in fact bypass ports, at least for outgoing signals.
Despite the fact that it is not declared in the entity's port section,
the LED does blink when I synthesize and upload this.
All I am asking is for a way to coerce XST to handle input signals in
a similar way.
Regards, Sidney
----------------------------------- blingbling.vhdl
library ieee, unisim;
use ieee.std_logic_1164.all,
ieee.std_logic_unsigned.all,
unisim.vcomponents.all;
entity toplevel is
port(CLK: in std_logic);
end entity toplevel;
architecture arch of toplevel is
signal LED : std_logic;
signal sig_led : std_logic;
attribute LOC : string;
attribute LOC of CLK : signal is "P184";
attribute LOC of LED : signal is "P20";
component OBUF is
port (O: out std_ulogic; I: in std_ulogic);
end component OBUF;
signal counter: std_logic_vector(23 downto 0);
begin
led_buf: component OBUF port map (O => LED, I => not sig_led);
process (CLK) is
begin
if rising_edge(CLK) then
counter <= counter + 1;
end if;
end process;
sig_led <= counter(23);
end architecture arch;
Article: 75281"rickman" <spamgoeshere4@yahoo.com> wrote in message news:4182813D.B18325F4@yahoo.com... > John wrote: > > > > Hi Rick, > > Three things come to mind: > > > > 1) The error message seems to be objecting the formal input "opcode", > > which is declared to be of type "IRSLV". Does changing the type to > > "standard_logic_vector" help at all? Maybe XST gets confused over type > > declarations. > > I haven't tried that. I check. > > > > 2) Perhaps the problem is in the function usage rather than the > > function itself. Can you show a code snippet where the function is > > called? > > This error happens when compiling the definition, not the useage. It > craps out on this file and never gets to the file where it is called. > > > > 3) I've had problems where stuff in a packaged library would not work > > unless the library was first 'compiled' by running 'check syntax' on > > the library package alone, separately from the design, in the ISE > > environment. Maybe this would help? > > Yes, this is being compiled and not just syntax checked. > > I am pretty convinced that this is an XST bug. The fact that it gives > the name LIT as the function name says something is pretty messed up. > But I am still open to the short between the headphones theory. > Just out of curiosity, does using a selected name work, e.g. return packagename.INSTDSPLY ? Alan -- Alan Fitch Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 mail: alan.fitch@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 75282
Sidney Cadot wrote:
> rickman <spamgoeshere4@yahoo.com> wrote in message news:<4185154A.25EEDBE0@yahoo.com>...
>
>>Sidney Cadot wrote:
>>
>>>I would like to keep the things that are different for each of the
>>>boards concentrated in my "memory mapped I/O" VHDL source, for which
>>>I have three versions - one for each board.
>>>
>>>However, since XST needs toplevel ports for all external ports, I am
>>>currently forced to have three different versions for two hierarchical
>>>levels of design above the "memmapped-io.vhdl" as well, namely my
>>>toplevel design (toplevel.vhdl) and the MMU (mmu.vhdl) that routes
>>>between the CPU and the RAM, ROM, and I/O apertures. The only reason I
>>>need three versions of my toplevel and mmu entities is that I must
>>>hook up some external pins into the mmapped_io entity.
>>
>>Maybe I am being a little dense today, but I still don't understand. If
>>your IO functions are the same why would you need different ports? What
>>is different between the boards that you can't just describe the
>>differences in the IO pin assigments in the UCF file?
>
>
> I failed to make that particularly clear (sorry). There are hardware
> differences, e.g.
>
> * The number of seven-segment displays 0/1/4
> * The number of LEDs 4/8/8
> * The number of push-buttons: 2/3/4
> * The number of sliding switches: 0/4/8
> * The availability of AD/DA's on the development board
> * The interface to memory residing on the memory board
You could select between these with active internal logic, or if you
know the difference at compile time, with generate statements or by
passing generic values into the entities, right?
I still must be missing something... I don't see how pushing the pin
location assignments deep into the hierarchy makes anything easier. You
can always make the bus wider need it needs to be to the top level - the
tools will optimized it down to the correct width.
>>Even if you don't use a port, don't you still need different top level files?
>
> I don't see why that would be necessary.
Unless it is necessary because some tools require it. :-) I don't
pretend to know if VHDL requires the ports to be at the top level or
not, but it would not surprise me if some of the tools don't handle it
correctly.
Have fun,
Marc
Article: 75283I posted here before and got excellent responses, could you knowledgeable people also answer a simple questuion below? If you reply by email, REMOVE "SPAMNOMORE" in capital letters repeated in my address twice (edit address manually)!! We need to make sure Xilinx VirtexProII FPGA boards have a PCMCIA interface (hardware) and software support, and whether inteface is a regular one usable with standard IEEE802.11 cards (WIRELESS LAN modules). The two boards (need info for BOTH!!) are: ML 300 and ML310 One is just a board another is a complete development kit, I am not sure yet. I did contact Xilinx first, but here's what happened: At first Xilinx engineers said PCMCIA is not supported, but then came back to me saying this: ML300 board: the PCMCIA supported, whereas PCI is supported only with much more effort on our side. ML310 board: The opposite (i.e. the PCI is supported, while the PCMCIA is not fully supported.) Thus we're completely confused and need to double check these answers, before comitting time/money. I CAN"T CONTACT THEM ANYMORE FOR THE SAME QUESTION AS MY XILINX PERSONAL ID HAS ALREADY BEEN USED FOR THE SAME QUESTION, I'd appreciate if you help.Article: 75284
hello, I design a compactflash interface between pci and a sandisk compactflash with true-ide mode, but I have some problem now. after reset, I try to read the status register of CF, I got 0x58. When I try any ATA commands like read sectors or set features ( set CF to PIO mode), I got 0x59 from status register. What is the matter? I think I make the read/write sequence right. BTW, the timing parameters I used is PIO-0. Thanks!Article: 75285
"Mark Levitski" <MetalBladeSPAMNOMORE@SPAMNOMOREprodigy.net> wrote in message news:Tuphd.25819$Qv5.25281@newssvr33.news.prodigy.com... > I posted here before and got excellent responses, could you knowledgeable > people also answer a simple questuion below? If you reply by email, REMOVE > "SPAMNOMORE" in capital letters repeated in my address twice (edit address > manually)!! > > > We need to make sure Xilinx VirtexProII FPGA boards have a PCMCIA interface > (hardware) and software support, and whether inteface is a regular one > usable with standard IEEE802.11 cards (WIRELESS LAN modules). The two > boards (need info for BOTH!!) are: > ML 300 and ML310 > One is just a board another is a complete development kit, I am not sure > yet. Hi Mark, 1) ML300 is considered "being phased out" - people had trouble attempting to buy it. So its possible out of the question anyway as you simple may not get it at all any more. as of your specific question for PCMCIA support - I would say expect about 1 month of engineerig time from your site, no matter what FPGA platform you choose (ML300 or ML310). Maybe some other vendor has something that requires less time for you to accomplish what you need. AnttiArticle: 75286
Tom Seim wrote: > jm_contact2002@yahoo.fr (jerome) wrote in message news:<96a74216.0410280152.436c4fc3@posting.google.com>... > >>Hello, >> >>Could someone give me information about the Nuhorizon Spartan-3 >>Development Board? >>It seems to be a good one based upon the Spartan-3 400 thousand gate >>FPGA (XC3S400-4PQ208C). >>Could someone confirme me I can use it with the ISE Webpack 6? >>A contact in NuHorizon told me I need full software, but I don't >>understand. >> >>Any other comment or suggestion? >> >>Thanks, >> >>Jerome. > > > We have had an extremely negative experience dealing with Nu Horizons. > They "take" orders, then don't deliver. After very persistent calling > they deliver partials, some of which are defective. > > Don't deal with them-they are VERY UNRELIABLE!!! I thought, I would be the only one ... Ordered this board, because it was in stock with overnight shipping, after few days checked again, NO STOCK, NOT AVAILABLE, please call ... Tried to reach anybody at the web-order number, for more than 3 weeks (at least twice a week), they don't return phone calls. After three weeks, I canceled my order via phone. Few minutes later I got a guy on the phone from NuHorizon saying, they got a board in (1?), and could ship it immediately. But at this time, I really had enough ... Looking at mail from other people and their expierence with that board, I guess, I'm pretty happy without ;-)Article: 75287
whizkid@gamebox.net (whizkid) writes: > Hi all, > what is the max frequency you have achieved with TSMC 18um library. > I an trying to synthesise a design at 528Mhz(1.8ns). Design Compier > results shows that the synthesis timing constraints were met. But when > I do netlist simulations I am getting 1000's of timing violations...I > checked the verilog simulaton model for the library and found that the > setup and hold checks are done in the library for 1ns ... ie for a > clock edge I need 1+1 ns for just satisying the setup hold > constraints... well my doubt is why the DC tool says the timing > constraints are met.. do you have any idea. Sounds like you haven't backannotated the netlist with SDF. Kai -- Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>Article: 75288
Sidney Cadot wrote: > > rickman <spamgoeshere4@yahoo.com> wrote in message news:<4185154A.25EEDBE0@yahoo.com>... > > > Even if you don't use a port, don't you still need different top level files? > > I don't see why that would be necessary. I am missing something. Are you planning to instantiate your IO ports in low level modules or in the top module? The example you gave is using the top module, but I guess that was a simplification. If you are trying to put the IOs into lower level modules, you may find this is a bit difficult to keep track of. But that is just a style preference. -- 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: 75289
Alan Fitch wrote: > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > news:4182813D.B18325F4@yahoo.com... > > John wrote: > > > > > > Hi Rick, > > > Three things come to mind: > > > > > > 1) The error message seems to be objecting the formal input > "opcode", > > > which is declared to be of type "IRSLV". Does changing the type to > > > "standard_logic_vector" help at all? Maybe XST gets confused over > type > > > declarations. > > > > I haven't tried that. I check. > > > > > > > 2) Perhaps the problem is in the function usage rather than the > > > function itself. Can you show a code snippet where the function is > > > called? > > > > This error happens when compiling the definition, not the useage. > It > > craps out on this file and never gets to the file where it is > called. > > > > > > > 3) I've had problems where stuff in a packaged library would not > work > > > unless the library was first 'compiled' by running 'check syntax' > on > > > the library package alone, separately from the design, in the ISE > > > environment. Maybe this would help? > > > > Yes, this is being compiled and not just syntax checked. > > > > I am pretty convinced that this is an XST bug. The fact that it > gives > > the name LIT as the function name says something is pretty messed > up. > > But I am still open to the short between the headphones theory. > > > > Just out of curiosity, does using a selected name work, e.g. > > return packagename.INSTDSPLY Just like I suspected all along, it was a user error. I had a function with the same name as an enumeration value. The other tools seemed to figure it out by context, but XST didn't like it. So I have fixed that, but I am getting another set of errors where it does not like my constants I think. I have defined a set of constant SLVs to match my opcodes. To make defining them easier I entered their values as function calls... constant LTRL : INSTVAL := TO_INTEGER(INSTBITS'(0,0,0)); -- 0 - 00 constant NOP : INSTVAL := TO_INTEGER(INSTBITS'(7,0,0)); -- 1 - 80 constant CALL : INSTVAL := TO_INTEGER(INSTBITS'(0,1,2)); -- 2 - 87 INSTBITS is an array of three integers (range 0 to 7) which TO_INTEGER converts to a single integer equal to the weighted sum, (i.e. binary positions to integer value). Logically this works and again, two other tools compile this just fine. XST barfs when I try to use one of these constants as a case statement choice saying "Choice call is not a locally static expression". Does the use of a function in a constant initialization make the constant not "locally static"? I tried looking in the LRM for a definition of "locally static" and could not find it. I did find on a web page that a locally static expression (LSE) can be either a literal, a constant that is init'd by an LSE or a call to an "implicitly predefined operator". So I guess my function calls make my constants only globally static and not locally static? -- 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: 75290
Marc Randolph <mrand@my-deja.com> wrote in message news:<vf-dnWXXTflpvxvcRVn-vg@comcast.com>... > I still must be missing something... I don't see how pushing the pin > location assignments deep into the hierarchy makes anything easier. It enhances the maintainability of the code, by concentrating all the knowledge about the particular hardware devices available in one place. For example, adding support for yet another board is then a matter of making one "mmapped_io_<boardtype>.vhdl" and recompiling. > You can always make the bus wider need it needs to be to the top level - the > tools will optimized it down to the correct width. This is one of many options to work around the problem. > >>Even if you don't use a port, don't you still need different top level files? > > I don't see why that would be necessary. > > Unless it is necessary because some tools require it. :-) I don't > pretend to know if VHDL requires the ports to be at the top level or > not, but it would not surprise me if some of the tools don't handle it > correctly. That's very true. The fact that XST seems to handle non-toplevel outgoing signals fine but isn't able to recognize incoming signals as drivers suggests the possibility that it is just a problem in XST. Cheers, SidneyArticle: 75291
alann@accom.com (Alan Nishioka) wrote in message news:<a2db9b48.0410312049.a22a5ae@posting.google.com>... > Can I safely connect Xilinx fpga pins to an external connector in a > commercial product? I do this, but not on a truly external connector, i.e. not one that leaves the box. It's generally O.K. to have mezzanine connectors, but your guess on ESD is correct if you want an external cable plugged in. > I want to be able to control direction and use them in some yet to be > determined manner. > Will this be a problem for esd testing? > Am I asking for someone to zap the most expensive part in my box? Yes. > What circuitry should I add to protect the fpga? I'd say the best way is to insert transceivers, but that would require picking a logic family. At a minimum I'd put Schottky clamps on the lines and even better something like a QuickSwitch if you can afford the delay due to on resistance and capacitive loading. > > Alan Nishioka > alann@accom.comArticle: 75292
sidney@jigsaw.nl (Sidney Cadot) wrote in message <snip> > > All I am asking is for a way to coerce XST to handle input signals in > a similar way. > > Regards, Sidney <snip> As others have already mentioned, one can use generic and conditional generate statements to customize the designs. I'm not aware that standard VHDL has a preprocessor #ifdef mechanism. There appear to be some third party offerings. One may easily write one that does the job with sed (less than 10 lines). The method that you are pursuing may not work in future version of the tools, but that is really for you to decide. A possible solution to get around the dilemma you face is to use an IOBUF instead of an IBUF, and strap the T pin so the output is always tristated. I personnally do not recommend going this route, but it is really your call. NewmanArticle: 75293
Hi Chris, > This isn't the perfect solution, but in verilog you could do something > like use a define to set the board type and then a bunch of ifdef's to > monkey with the port lists on the higher level modules. You could > even use an ifdef to instantiate the correct hardware specific > low-level module. If you don't want to contaminate the top-level > files, you can include the portions that are different out of other > files. Basically, the idea is to use the pre-processor rather than > the HDL's abstraction model to hide the hardware details. I'm sure > there's a similar mechanism in VHDL? I'm afraid there is no mechanism analogous to textual preprocessing like we have in C for VHDL. Nothing is keeping me from using a preprocessor despite that, of course, but life would be just so much easier if I can solve this at the VHDL level. > Okay, it's not perfect, but it works for C programmers writing > multi-platform code... (What's really cool is if you run the whole > thing with a makefile, you can pass the matching parameters not only > to the hdl complier, but also to the compiler of the software that > runs on your SoC) Well I do tie everything together using a Makefile, I could easily insert a preprocessing stage ... but this would make my stuff considerably less easy to re-use for other people (I intend to publish the project on the Web). > PS - these spartan 3 kits are fun... with the addition of one chip and > a bunch of resistors, Yes, it is great stuff. I implemented a 6502 from scratch, which uses the internal block memory of the Spartan-III .... I implemented a very small machine language monitor program that works via the RS232, and I must say it's really something to type to this little computer and get a response that shows it works - also happy to be able to rehash those old 8-bit skills I picked up 20 years ago :-) I can also run C programs on this thing (using CC65, www.cc65.org) which is perfect. It's been a very educational project so far, I've had several occasions to think "so _that_'s why they do it like that!" :) The digilent/xilinx kit is quite fantastic and really a bargain, at a hundred bucks including the JTAG cable and power supply. I was especially happy with the quality of hardware documentation they provide, after horrific experience in this respect with my NuHorizons kit. The Memec kit I have is also nice by the way, I also have their 50 MHz AD converter kit I use for experiments. Great stuff. > I have one of the digilent ones pulling pictures > off an IDE hard drive and generating a color composite NTSC signal to > drive a little LCD tv... Sounds great! I have been thinking about implementing an IDE interface myself, do you have any more info, e.g. did you implement the IDE core yourself? Regards, SidneyArticle: 75294
sidney@jigsaw.nl (Sidney Cadot) wrote in message news:<741e0fbf.0411010028.3ea1a7f3@posting.google.com>... > newman5382@aol.com (newman) wrote in message news: > > The "external view" (VHDL wise) of my "mmapped_io" component is > basically that it acts like a RAM block, i.e., it has a data bus and > an address bus, and R/W control bits. The fact that these happen to do > some interesting things to hardware, should be of no concern to the > VHDL modules that instantiate an "mmapped_io" component, that's the > whole point of having memory mapped I/O. As I think about this more, it looks to me like you're not really architecting this in a way consistent with the philosophy of a hardware description language. Remember, this is sort of a software equivelent to putting chips on boards and wiring them together. So unless one of your chips happens to be something "magic" like a self-contained RF module, nothing gets into or out of a chip unless you provide traces on the board to get it there. Software engineers get pure abstaction; hardware engineers just get 3ghz wire wrap guns. From that point of view, I think you should think of your universal bits of code as modules with no real-world I/O - for example, your CPU, any on-chip memory, any other internal functional blocks. Build those into a library of general purpose functions that you can use in any of your projects. Then for each specific FPGA board, create a top-level module with the actual physical I/O ports. This module should then instantiate a mix of both your library of internal functional modules like CPU, and hardware-specific handler modules for the specific board like your memory mapped io function. You will of course have to wire the physical I/O ports through to those modules which need them, possibly leaving any extrnal tri-states in the top level and passing something back up to control them. And of course if you do system simulation, you would in turn treat the formerly top-level module as just one component in a testbench module where it gets wired up to simulations of whatever your board talks to... ChrisArticle: 75295
Sidney, > I failed to make that particularly clear (sorry). There are hardware > differences, e.g. > > * The number of seven-segment displays 0/1/4 > * The number of LEDs 4/8/8 > * The number of push-buttons: 2/3/4 > * The number of sliding switches: 0/4/8 > * The availability of AD/DA's on the development board > * The interface to memory residing on the memory board I have noticed that XST will remove pins at the top level of a design that are not connected. Hence, you could create a design with the maximum number of pins you need at the top level and then control whether the functionality is in the design or not with generate. Control the generate with constants from a package. Have one package for each board configuration. I am not sure what other synthesis tools do with IOs so this may not work for all synthesis tools. If you have excess IO, you can be even lazier. Skip the generate statements, implement all of the functionality in the device, but allow unused functionality connect to unused device pins. This works well for outputs, but for inputs, your design may have to be configured to ignore the unused ones. I use this to make some of our lab projects work on different FPGA boards (Xilinx and Actel for now). VHDL does not have any conditional statements outside of generate, however, it would be simple enough to use CPP as a preprocessor and script your compiles to always use CPP - of course that would mean that everyone that uses the files would have to do this also. I have done some experiments with this and it seems to work easy enough. Cheers, Jim -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787 Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Article: 75296
>I'm not aware that standard VHDL has a preprocessor #ifdef mechanism. >There appear to be some third party offerings. One may easily write >one that does the job with sed (less than 10 lines). Standard cpp works fine. Everything gets much saner if you have a makefile. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 75297
I work at a university, and we just got a bunch of FPGA boards with Spartan 2E's on them. It's like five weeks into the quarter, and already 6 of 20 boards have died. I contacted tech support for the board manufacturer, and it seems that the FPGAs have been "fried" on all six of the bad boards, judging from the fact that both the onboard voltage regulators and FPGAs both get really hot, and the power-on LED fails to turn on. Looking at the boards very closely I see no signs of physical mistreatment though. The boards are being programmed using jtag cables + iMPACT with bitfiles created with Foundation. At first I thought that maybe a backward jtag cable would fry the FPGA, but it turns out that's not the case. Really I have no idea what people could be doing to these boards. So here's my question: How do you fry an FPGA?? I guess running like 50 volts through it would do the job, but I don't think the cause of these failures is a malicious user. Is there anyway to "accidentally" synthesize a design that causes an FPGA to destroy itself??? Thanks for the help.Article: 75298
"zerang shah" <ninjak@gmx.de> wrote in message news:4d6c559c.0411011707.fba22e8@posting.google.com... > So here's my question: How do you fry an FPGA?? I guess running like > 50 volts through it would do the job, but I don't think the cause of > these failures is a malicious user. Is there anyway to "accidentally" > synthesize a design that causes an FPGA to destroy itself??? > > Thanks for the help. A bit of olive oil in a frying pan at high heat should do it. They are delicious, especially with Lattice! Clyde TorresArticle: 75299
Hi all, I created a system generator file to use the DDS core, and when I try to simulate, it gives the following error: Input width should be equal to accumulator width. I created the DDS module with phase increment as "register", and phase offset constant, and output width set to 27. The number entering the DDS Data port is also 27 bit. What's going on, and what does the error mean? Thanks, Vadim
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