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
"Salman Sheikh" <sheikh@pop500.gsfc.nasa.gov> schrieb im Newsbeitrag
news:ee74dea.0@WebX.sUN8CHnE...
> All,
>
> I am getting the following message on my place and route.
>
> WARNING:DesignRules:372 - Netcheck: Gated clock. Clock net
> fsync1/CPUINTERFACE_0/loop13_un187_cpu_addr is sourced by a
combinatorial
> pin. This is not good design practice. Use the CE pin to control the
loading
> of data into the flip-flop.
In general, gated clock should not be used within FPGAs. But the code below
creates a LETCh (not a FlipFlop), where the gate signal is created by a
combinatorical logic. No good.
>
> I believe its due to this code:
> ---
> library IEEE;
> use IEEE.STD_LOGIC_1164.all;
> use IEEE.STD_LOGIC_UNSIGNED.all;
> use IEEE.STD_LOGIC_ARITH.all;
> use WORK.PIFSTYPES.all;
>
> entity CPUWRTGEN is
> port
> (CPU_ADDR :in BIT11;
> WRT :out BIT31);
> end CPUWRTGEN;
>
> architecture BEHAVIOR of CPUWRTGEN is
>
> signal CPU_ADDR_INT : INT63;
>
> begin
>
> CPU_ADDR_INT <= conv_integer(CPU_ADDR(5 downto 0));
>
> process(CPU_ADDR, CPU_ADDR_INT)
> begin
> for I in 39 downto 9 loop
> if CPU_ADDR (10 downto 6) = "01000" and CPU_ADDR_INT = I then
> WRT(I-9) <= '0';
> else
> WRT(I-9) <= '1';
> end if;
> end loop;
> end process;
>
> end BEHAVIOR;
> --------
> I also get a complaints in Synplify when synthesizing, like so:
>
> Found clock
fsync1.CPUINTERFACE_0.CPUWRTGEN_0.loop37_un19_cpu_addr_inferred_clock with
period 1000ns
>
> Now my question is how can I change my code so that I can eliminate these
warnings, as its not a good design practice.
In general, you should better design synchronous. This means, you system has
a clock signal. So is could be rewritten as
process(clk) -- depends only on CLK
begin
if clk='1' and clk'event then -- this is the rising edge of
you clock signal
for I in 39 downto 9 loop
if CPU_ADDR (10 downto 6) = "01000" and CPU_ADDR_INT = I then
WRT(I-9) <= '0';
else
WRT(I-9) <= '1';
end if;
end loop;
end if; -- end of clocked process
end process;
end BEHAVIOR;
--
MfG
Falk
Article: 39701Hallo! usgoxy@yahoo.com wrote: > ake a look at this great soft porn site !! I've been looking at this site, and now I'm confused. What is the difference between the MAX3000A series and MAX7000A (or AE) series? Both seem to come in similar densities, packages and speeds. Where would one get small quantities (in the UK, preferably) of these devices? Some varieties seem to be stocked by Farnell and RS but they seem to be only obsolete devices (and stupid prices) -- a bit like those ISA parallel printer interface cards you can buy from their catalogues at $200 apiece. Frank -- ------------------------------------------------------------------------ Frank A. Vorstenbosch <SPAM_ACCEPT="NONE"> Phone: +44-7976-430 569 Wimbledon, London SW19 frank@kingswood-consulting.co.ukArticle: 39702
My current employer has an application where I might want to use one of the "C for hardware" type languages. Basically, there is a sizable chunk of ANSI-C code that might need to be put into hardware to improve system performance. Before this needs to be started, and it is not clear yet if it truly does need to be done, I'd like to learn more. Methods for doing this might might be to convert this C code into hardware-c (Handel-C or System-C), or to hand convert the C into VHDL, and then verify the conversion by simulation (read lots of effort) or to hand convert the C into VHDL and then verify the conversion by some "formal verification" method. The first alternative brings up a bunch of issues. The tools are fairly new: it seems slightly unlikely to me that "pushing the envelope" type hardware could be built. Is this true? I sat in a Celoxica sales pitch, and the examples given were running at 40 MHz or so. Sorry, but that's not impressive: the parts can easily do 66MHz+ with very little detailed effort, with a high level VHDL (or Verilog) design and almost push-button flow, and 133Mhz, while it does take more effort just isn't that hard. The tools don't appear have features needed to push the design to higher speeds, such as a schematic viewer to quickly answer the question, what did my code build into? I don't know what sort of support in any of the "hardware-C" tools for physical design, is there any? The users (me for example) don't understand the whole process: I can read C and eventually understand what it's doing, I've written some C code, but I don't have experience in translating ANSI-C into hardware-C or in writing hardware C. How hard is this to learn? How hard is this to learn to do well? Meaning how hard is it to produce close to minimum sized hardware that runs fast? Then there is the question of the different variations of hardware-C. Opinions on which is best? (Cue in the VHDL vs Verilog flame war part 2) The second alternative I understand how to do, it is just work, and there is absolutely nothing wrong with that if it's the best option, yet I'd rather do it faster and easier, or faster and fewer bugs... The third alternative is formal verification. I have no experience in such tools, so does anyone have experience, opinions (or both) on the question of would this help to produce FPGA hardware that matches the original C? -- Phil HaysArticle: 39703
Are they still in business? Who owns them now? Are they worth considering for new designs? If so, why don't they get mentioned here more often? -- These are my opinions, not necessarily my employer's. I hate spam.Article: 39704
>- I have worked with Texas' DSPs boards before. In that, I load >programs and debug the application with JTAG interface. I understand >Virtex devices have the same interface. Is software provided by these >people similar in this way to DSP's software? Is it possible to write >a program and inmediately load it in FPGA? In general, using JTAG on FPGAs is very similar to using it on DSPs. The key idea is that you don't have to take your code over to a ROM blaster and swap in a fresh ROM on your debugging setup. But you might not use the term "inmediately" if you have a complicated FPGA design. It can take hours to "compile" your program. Hand tweaking to help the placer/router is often required. Usually you can make minor changes without having to rework/repeat much of that. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 39705
hamish@cloud.net.au wrote: > Rick Filipkiewicz <rick@algor.co.uk> wrote: > > Is it possible to use 4.1i speed files when building with 3.3i ? e.g. for an > > XCV600E I could just copy over the %XILINX%/virtexe/data/v600e.spd from my 4.1i > > installation to my 3.3i one ? > > No, you'll get error messages about the file format version numbers > being different. (I tried it.) > > Hamish > -- > Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au> Oh b******s! So its back to the ``exposed butt'' position or use 4.1i.Article: 39706
"FPGA/IC" <wagain@21cn.com> wrote: > when I use verilog for the entry design, do I need to write the tester code > respectively for pre-simulation and postlayout simulation? That means two > different test codes? No. The same code. Please refer to http://www.model.com/resources/appnotes/fpga_flow.asp --IKArticle: 39707
Phil Hays <spampostmaster@attbi.com.com> writes: >My current employer has an application where I might want to use one of the "C >for hardware" type languages. Basically, there is a sizable chunk of ANSI-C >code that might need to be put into hardware to improve system performance. >Before this needs to be started, and it is not clear yet if it truly does need >to be done, I'd like to learn more. Methods for doing this might might be to >convert this C code into hardware-c (Handel-C or System-C), or to hand convert >the C into VHDL, and then verify the conversion by simulation (read lots of >effort) or to hand convert the C into VHDL and then verify the conversion by >some "formal verification" method. Personally, I don't believe in the C to hardware idea. All the algorithms that I would think of doing it for are coded completely different in hardware than software. For example iterative or recursive algorithms in software might be systolic arrays in hardware. If you are going to completely rewrite the algorithm, it doesn't seem that it will help your problem. If you could give a basic idea of what kind of algorithm it is, that would help. -- glenArticle: 39708
Phil Hays <spampostmaster@attbi.com.com> writes: > Methods for doing this might might be to convert this C code into > hardware-c (Handel-C or System-C), or to hand convert the C into > VHDL, and then verify the conversion by simulation (read lots of > effort) or to hand convert the C into VHDL and then verify the > conversion by some "formal verification" method. You might want to review the offering from Proceler (www.proceler.com). They advertise a system that automatically partitions your C code into hardware and software, targetting the hardware to an FPGA and the software to a CPU. KellyArticle: 39709
I heard that Agere (a spin off from Lucent) sold their still profitable FPGA business to Lattice recently. Agere inherited a lot of debt from Lucent, so I guess they figured selling their FPGA business will help pay some of their debt. However, I also read an EE Times article a few months ago that Lattice has its own internal FPGA development program, which sounds like they inherited from Vantis. Before Lattice bought Vantis, Vantis had an FPGA called VF1, so I presumably think this internal project is a follow-on of VF1. Kevin Brace (Don't respond to me directly, respond within the newsgroup.) Hal Murray wrote: > > Are they still in business? Who owns them now? > > Are they worth considering for new designs? > If so, why don't they get mentioned here more often? > > -- > These are my opinions, not necessarily my employer's. I hate spam.Article: 39710
I am not paid to say this, but if you want to get started with FPGAs, I recommend that you start with Xilinx FPGAs. The reason I recommend Xilinx over Altera or other vendors is that Xilinx's free ISE WebPACK comes with a decent synthesis tool (XST) and a starter version of ModelSim XE. The starter version of ModelSim XE has a 500 lines code limitation, but fortunately, the simulation only gets slow after 500 lines, and you can still simulate your design beyond 500 lines. For development boards, Insight Electronics has some development boards, but other vendors like Avnet or NuHorizon also have some development boards. http://208.129.228.206/solutions/kits/xilinx/ The reason I will not recommend Altera devices will be that Altera doesn't offer a free version of ModelSim like Xilinx, their tools (MAX+PLUS II-BASELINE or Quartus II 1.1 Web Edition) are buggy compared to Xilinx ISE WebPACK, and I haven't seen many low cost development boards with Altera FPGAs (Low cost means < $200.). I am sure Altera fans of this newsgroup won't be happy of what I wrote, but that is my opinion. Kevin Brace (Don't respond to me directly, respond within the newsgroup.) Dani Guzman wrote: > > Hi, > I have no experience using FPGA. I have to choose some family, from > Altera or Xilinx. I suppose both should have a family that suits my > needs, but I need some advice considering what I have to do: > > - I have to do a PCB w/FPGA logic. Main requirement is to include > in-system reconfiguration, I mean, to change code loaded in FPGA > without desoldering the device. I have learned that a configuration > PROM is in charge of this, or even a JTAG interface. Is it correct? Do > I need a CPU to control FPGA as well? > > - I have worked with Texas' DSPs boards before. In that, I load > programs and debug the application with JTAG interface. I understand > Virtex devices have the same interface. Is software provided by these > people similar in this way to DSP's software? Is it possible to write > a program and inmediately load it in FPGA? > > - Which family should be best choice considering I have to design a > PCB w/reconfiguration capability? > > - I'm thinking in buying a demo board to achieve experience w/FPGA > programming, which one is convenient, considering I have to implement > a PCB ? Is it a good choice to think in a demo board or it's better to > study and design the PCB right now? > > Thanks in advance. > > -Dani-Article: 39711
Formal verification is generally used to verify gate level netlists are equivalent and is used when designing ASICs. I think of formal verification at the HDL level as doing simulation equivalence checks. If you are converting an algorithm written for a CPU to a hardware algorithm, I would look at the size of the design as the determining factor. As for all projects, budget, schedule, manpower all are taken into consideration. If the algorithm is large and you can afford to purchase a software package like Handel-C, I would go for it. It is a cost effective way of getting what you need. It does have the capability of spitting out VHDL so you can simulate your result; don't expect to be able decipher what hardware was generated by looking at the VHDL code. The one nice thing we noticed using the Handel-C was that we could do a heck of a lot more architecture modifications in the same amount of time it would have taken in VHDL. Also, we were able to convert the ANSI-C to Handel-C in 1/30th the time it took to go to VHDL. As far as determining what speed at which the design runs, you have to place and route the design immediately to get the speed at which it will run. Handel-C has all the constructs to allow you to dictate the architecture; it just takes a couple days to get the feel for how it generates hardware. I have used it and have been happy with the results: easily passing 100MHz in Spartan II and 200MHz in Virtex II. We have used SystemC before also, but just for modeling and not for hardware generation. It was simple to use also, but we didn't want to buy the synthesizers from Adelante or Synopsys. Again though, it was a heck of a lot easier converting the C algorithms to usable code rather than converting it to VHDL. good luck "Phil Hays" <spampostmaster@attbi.com.com> wrote in message news:3C6EA440.ED3E96D3@attbi.com.com... > > My current employer has an application where I might want to use one of the "C > for hardware" type languages. Basically, there is a sizable chunk of ANSI-C > code that might need to be put into hardware to improve system performance. > Before this needs to be started, and it is not clear yet if it truly does need > to be done, I'd like to learn more. Methods for doing this might might be to > convert this C code into hardware-c (Handel-C or System-C), or to hand convert > the C into VHDL, and then verify the conversion by simulation (read lots of > effort) or to hand convert the C into VHDL and then verify the conversion by > some "formal verification" method. > > The first alternative brings up a bunch of issues. The tools are fairly new: it > seems slightly unlikely to me that "pushing the envelope" type hardware could be > built. Is this true? I sat in a Celoxica sales pitch, and the examples given > were running at 40 MHz or so. Sorry, but that's not impressive: the parts can > easily do 66MHz+ with very little detailed effort, with a high level VHDL (or > Verilog) design and almost push-button flow, and 133Mhz, while it does take more > effort just isn't that hard. The tools don't appear have features needed to > push the design to higher speeds, such as a schematic viewer to quickly answer > the question, what did my code build into? I don't know what sort of support in > any of the "hardware-C" tools for physical design, is there any? The users (me > for example) don't understand the whole process: I can read C and eventually > understand what it's doing, I've written some C code, but I don't have > experience in translating ANSI-C into hardware-C or in writing hardware C. How > hard is this to learn? How hard is this to learn to do well? Meaning how hard > is it to produce close to minimum sized hardware that runs fast? > > Then there is the question of the different variations of hardware-C. Opinions > on which is best? (Cue in the VHDL vs Verilog flame war part 2) > > The second alternative I understand how to do, it is just work, and there is > absolutely nothing wrong with that if it's the best option, yet I'd rather do it > faster and easier, or faster and fewer bugs... > > The third alternative is formal verification. I have no experience in such > tools, so does anyone have experience, opinions (or both) on the question of > would this help to produce FPGA hardware that matches the original C? > > > -- > Phil HaysArticle: 39712
hello Mr.Bernhard Holzmayer the solution for your problem is declare the port as std_logic__vectorthen you can directly asssign it as "zzzzzz". sharat babu "Bernhard Holzmayer" <Holzmayer.Bernhard@foerstergroup.de> wrote in message news:<a4fu7f$1f2fr7$1@ID-131763.news.dfncis.de>... > Hello. > > While doing my first steps with Xilinx System Generator (V2.1), I > hit a > (maybe trivial) problem: > > I have a port / pin, which is both, input and output. > It must be written depending on a flag's state, being high-Z > otherwise. > In VHDL it would be something like the following: > ... > ...process(flag, data) > begin > if (flag = '1') then > port <= "ZZZZZZZZ"; > else > port <= data; > end if; > end process; > > Help me: how can I set this port into the high-Z state using SysGen? > Does anyone know this ??? > > BernhardArticle: 39713
Marc, I hate to sound dumb, but that does not make any sense to me. If Xilinx claims that there may be differences in the bit streams required to program two families, then why would they not give them distinct JTAG IDs? I am especially surprised that the XCVe and the XC2Se families use the same IDs since they DEFINITLY have different bit streams due to the different block memory counts. Isn't the point of having IDs to be able to tell the different parts from one another??? Rick Collins Marc Baker wrote: > > There are variable amounts of don't care bits in the bitstream that account for > slight variations in counting the total bitstream length. The Spartan-II data > sheet has been updated a couple times since the 3/3/2000 version, with the > current one from March 2001 indicating the same bitstream length as the XCV100: > 781,216, which is the current bitstream length created by the Xilinx development > system. > > Bitstreams created for one family may work in another, but Xilinx does not test > the parts that way and cannot guarantee that they will work. We strongly > recommend creating the bitstream for the target device. > > The Spartan-II and Virtex families share the same JTAG family ID code, as do the > Spartan-IIE and Virtex-E families. The software ignores any variations in > revision, so it cannot differentiate between Virtex and Spartan devices of the > same CLB matrix. > > Kevin Brace wrote: > > > That is not true. > > According to Virtex datasheet dated 1/28/2000, the configuration bit > > length for XCV100 is 781,216. > > However, according to Spartan-II datasheet dated 3/3/2000, the > > configuration bit length for XC2S100 is 781,248. > > > > Kevin Brace (Don't respond to me directly, respond within the > > newsgroup.) > > > > Ray Andraka wrote: > > > > > > The bitstreams for virtex and spartanII for same size device are the same. > > > > > > > > > -- > > > --Ray Andraka, P.E. > > > President, the Andraka Consulting Group, Inc. > > > 401/884-7930 Fax 401/884-7950 > > > email ray@andraka.com > > > http://www.andraka.com > > > > > > "They that give up essential liberty to obtain a little > > > temporary safety deserve neither liberty nor safety." > > > -Benjamin Franklin, 1759 > > -- > Marc Baker > Xilinx Applications > (408) 879-5375 -- 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: 39714
The way you made your comment did not bother me at all. I assume you are using your sense of humor with comments like these. But I don't see how System Ace helps me at all. I looked at Ace a long time ago when it was first announced and realized that it was a way for designers of large systems to add huge configuration memories to their designs. I not trying to find a way to facilitate the selective downloading of hundreds of different designs. I am trying to find a way to eliminate the need for hundreds (or even thousands if we are very successful) of different designs. I know I have posted about this before, and the answer has always been, "We don't currently have a partial reconfiguration option, but have you looked at JBITS?" JBITS seems to be a good way to punt the problem off to the customers and leaves a lot to be desired in the way of design verification. But on the off chance that there has been some progress made in the last three months, I will explain in detail again. I am designing a very small DSP board which will use even smaller daughter modules to provide various types of IO. On the first iteration of this design we had two daughter module sites and used two FPGAs (one each) to provide the interface functionality to a common board bus to memory. This allowed us to check the ID of each daughter module at reset and load the FPGA with the design (bit stream) corresponding to the daughter module. Perfect! Now we are using four daughter modules per DSP board in the same amount of space. But we just don't have the space to use four FPGAs. In fact, we have less space due to the increased memory size and the relocation of a few parts that were in the locations of the two new daughter modules. So we have combined the former three FPGAs into one and added two more interfaces. This is going to make the number of FPGA bit streams jump to enormous numbers if we allow any module to be plugged into any site. Example: if we have just 3 different modules (which is our goal by the end of the year) we will need to support up to 3**4 = 81 different designs. Of course we can pare this down enormously by requiring only to support fixed locations for each combination (ie AABB and not ABAB or BABA...). But that still makes for 15 combinations. When we add three more new daughter module types next year, we will have an even larger number of designs to support. So the problem could be dealt with quite easily if we could use a modular design where the FGPA could be thought of as having blocks for each design and loading the corresponding interface into its own block. Even if we had to design four different designs for each module type, that would be 4*N rather than some geometric progression. As it is we expect that part of selling a board set to a customer will include the possibility of having to do a P&R of the modules along with a full qualification of that P&R including temperature testing. This will not be cheap and will significantly affect our business model. Any chance this can change your business model and find a way to support partial reconfiguration? This is not reconfiguration on the fly. Perhaps a better term would be modular design and configuration? Austin Lesea wrote: > > Rick, > > Good points. > > Doesn't System Ace solve some of your problems? It must be good (as Altera has > copied it, too!) > > Austin > > rickman wrote: > > > Austin Lesea wrote: > > > > > > Rick, > > > > > > Seriously, we didn't invent them, we just placed them in a fabric, and > > > supported them in the FPGA. And as it turns out, you can get a patent for > > > just that kind of assembly of non patentable items arranged in a new or > > > novel way together to perform an improved function. Altera, and we have > > > lots of patents, and now that the legal hassling is over, we can apply all > > > of our efforts to supplying our customers with the best possible products. > > > > > > I appeciate all of the comments, and it is absolutely critical that Xilinx > > > listen to customers, because that is what we did with Virtex, and Virtex II > > > (and are still doing). > > > > > > No time to fiddle around, I have the next two product generations to help > > > design, document, and support. > > > > > > Austin > > > > Be careful what you ask for, because you might just get it. You asked > > for my input, so here it is. > > > > I am not a high speed data/telecom vendor and I don't do gigabit IO. I > > use FPGAs for general purpose system "glue" and data movement > > operations. There is sometimes a little DSP thrown in for good measure. > > > > As it turns out, the single biggest limitation in FPGAs that I am facing > > is software. I need to be able to design a modular set of interfaces > > that can be loaded into the chip in different combinations at run time. > > There is no PC and no platform to run tools such as JBITS. There is a > > small micro and a sizable hunk of Flash memory. If I could store a dozen > > interchangable pieces that can be loaded into an FPGA in different > > combinations, it would save me from having to design perhaps as many as > > hundreds of different complete designs as distinct bit files. > > > > Any progress in this area? Not much point in making the chips bigger and > > bigger if your software doesn't keep up. > > > > -- > > > > 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 FAX -- 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: 39715
Lucent has always considered the FPGA business as a tool to get comms oriented ASIC business. If you have ever designed with their schematic entry you would have seen the common elements they used to facilitate this. This is also evident in the devices they have brought out over the last two years. They have all been larger parts many with dedicated components for comms interfaces. The bottom line seems to have been, if you are not a large comms vendor, they are not going to make an effort to get your business. I know that Altera and Xilinx also push very heavily to get business from the comms market, but they don't exclude the rest of the FPGA market in the process. We will see if Lattice does anything to improve or change this picture. I expect they will. BTW, the Lucent parts were originally made as spinoffs from the Xilinx 3K (actually identical) and 4K (the original ORCA parts, ATT1, IIRC). They continue to use the same basic architecture as Xilinx with LUTs usable as RAMs and many other features copied (licensed) from Xilinx. They even were the first in a few areas such as more than 2 LUTs and FFs in a CLB and a more structured routing pattern. I believe the current generation is the OR4C family with the OR2C/T and the OR3C/T still being offered for new designs. My last DSP board used the OR2T04 (very inexpensive) and an OR3T30. But the tools may be a problem. They will give you the back end tools, but you are on your own for the front end tools, even schematic capture, I believe. But Lattice may change that as well. Hal Murray wrote: > > Are they still in business? Who owns them now? > > Are they worth considering for new designs? > If so, why don't they get mentioned here more often? > > -- > These are my opinions, not necessarily my employer's. I hate spam. -- 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: 39716
FPGA/IC wrote: > > rickman <spamgoeshere4@yahoo.com> wrote in message > news:3C6D5519.BD2F7E28@yahoo.com... > > Dani Guzman wrote: > > > > > > Hi, > > > I have no experience using FPGA. I have to choose some family, from > > > Altera or Xilinx. I suppose both should have a family that suits my > > > needs, but I need some advice considering what I have to do: > > > > > > - I have to do a PCB w/FPGA logic. Main requirement is to include > > > in-system reconfiguration, I mean, to change code loaded in FPGA > > > without desoldering the device. I have learned that a configuration > > > PROM is in charge of this, or even a JTAG interface. Is it correct? Do > > > I need a CPU to control FPGA as well? > > > > First, let me say that in terms of configuration, there is very little > > real difference between the two vendors you mention. You can use a > > (EE)PROM to configure the FPGA or you can use a micro. But JTAG is not a > > viable option for normal operation of your board. JTAG is used during > > debug to save the trouble of downloading designs to the (EE)PROM or to > > what ever storage your micro is using. > > Did you mean that Xilinx's FPGA need a PROM for reconfiguration, while > Atera's dont need, it is directly download in the FPGA? how about Actel's? > > thanks No, I thought I made that clear when I said that "First, let me say that in terms of configuration, there is very little real difference between the two vendors you mention." Both vendors support several options including loading from a serial (EE)PROM, loading from a parallel (EE)PROM (on mostly older chips), loading from a micro either serial or parallel and finally loading via JTAG. My point about JTAG is that this needs a PC to run the software. It may be possible to drive a JTAG port from a micro, but you will have to write your own software, if I understand it correctly. So normally, JTAG is only usable while debugging a system when you have a PC around. In an embedded system, you will need to load via a micro or a PROM of some form. If I am familiar with Actel's parts, they are fuse programmable and are only programmed once. To change their programming, you need a soldering iron and a new part. This is a special subset of ISP that most vendors don't offer ;) -- 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: 39717
Ulf Samuelsson wrote: > > > I have no experience using FPGA. I have to choose some family, from > > Altera or Xilinx. I suppose both should have a family that suits my > > needs, but I need some advice considering what I have to do: > > > > - I have to do a PCB w/FPGA logic. Main requirement is to include > > in-system reconfiguration, I mean, to change code loaded in FPGA > > without desoldering the device. I have learned that a configuration > > PROM is in charge of this, or even a JTAG interface. Is it correct? Do > > I need a CPU to control FPGA as well? > > > Hi Dani, You can check out the Atmel AT17 family of In System Programmable > Configurators. > Atmel has an interesting chip, the FPSLIC which combines a processor and > a 5k/10k/40k gate FPGA > There will in a couple of months be a JTAG version, and hopefully it > should be possible to download the FPGA AND CPU over JTAG using the standard > AVR controller JTAG-ICE. Does that mean that the JTAG-ICE will support debug with the device in a scan chain? I am interested in using the AVR ATmega64 or 128 in a design with boundary scan and a couple of FPGAs. But I am being told even though the ATmega chips support boundary scan and JTAG debug, the software doesn't support JTAG debug with the chip in a scan chain!!! Boundary scan without a scan chain does not make a lot of sense. It would make some sense that when they change the software to handle the two devices in one chip, they might fix the software to handle a chip in a scan chain as well... -- 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: 39718
There are a lot of different opinions about whether you need to run post layout simulation or not. There are two main schools of thought. One says that there can be subtle errors introduced that a simulation MIGHT be able to catch. The other says that the errors are primarily timing errors and should be caught in a static timing analysis which all back end tools (Place and Route) support. I am from the static timing analysis school. If you keep your design synchronous and don't use any "tricks", you will find that static timing analysis will check your design 100%, provided that you specify your timing constraints correctly. Correct timing constraints are the main fly in the ointment for this process. The vendors have provided good tools for applying your timing constraints, but have come up with virtually NO tools to verify that your timing constraints are correct or to even help you verify how your timing constraints are being interpreted. The post layout simulation school applies the same simulation to the design after P&R. This can find timing and possibly other errors (but I don't know what they would be in a synchronous design). But there is no guaranty at all that your simulation will check very much of the design (this is called coverage). The timing analysis in a post route design is not even very good since it has to work with a single set of timing numbers (normally the slowest). Many timing problems that would not be caught with static timing analysis would require either the fastest or a mix of fastest and slowest timing data. So post route simulation has a poor chance of finding anything but gross timing errors. They also flag a lot of problems that are not problems having to do with metastability and startup conditions. FPGA/IC wrote: > when I use verilog for the entry design, do I need to write the tester code > respectively for pre-simulation and postlayout simulation? That means two > different test codes? > > thanks. -- 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: 39719
Ray, I would like to draw on your experience if I can. I am looking at doing a SDRAM and SBSRAM interface in an XC2SE chip and would like to get an idea of what speed grade I will need. Turns out that the DSP chip will only support up to 100 MHz on the memory bus so I won't have to push the speed much. Will this be easy on the slowest speed grade which seems to be a -6? Since there only seem to be two speed grades at this time, I don't expect to see that much difference (and no industrial in the -7). I can't tell from the data sheet as it does not have data for the -7 yet (even though I can buy the parts). From your experience will a 100 MHz SDRAM interface be easy in a XC2S200E-6 ? Ray Andraka wrote: > > Venu wrote: > > > Hi, > > > > I am planning to implement a SDRAM Controller to run at 133MHz and I am > > targetting Virtex-II device. It would be of great help to me if people > > can let me know their experiences in this regard . More specifically I > > am looking for some inputs on the following: > > > > a) Is this freq of 133MHZ for SDRAM Controller easily achievable in a Virtex-II > > device > > Should be very easy to hit 133 Hz in VII. Of course, it depends on your design > expertise, which is why I said "should" not "is". > > > > > b) What is the Max frequency that Xilinx claims in their application-notes > > for SDRAM Controller using Virtex-II > > > > Thanks > > Venu > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 -- 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: 39720
I see that this question has met with no reply after two weeks. I guess that is the answer... Russell Shaw wrote: > > Guy Schlacter wrote: > > > > QuartusII v2.0 just released Friday and has been producing very good > > results for both this new family and ApexII. > > When is Quartus web edition going to include Acex 1k devices? > > > As far as GATE COUNTING, every vendor and family uses differnet > > nomenclature. For the user, you are best off descregarding gate counts > > and comparing > > 4input LUTs > > Available Memory counts > > Other dedicated Resources Multipliers etc. > > > > Best of Luck, > > Guy Schlacter > > Altera Corp. > > > > "Steve Holroyd" <spholroyd@iee.org> wrote in message > > news:b623f4cf.0201111039.2a16155@posting.google.com... > > > > > I am currently task of recommending the largest, fastest and most > > > memory FPGA that's readily available the first half of this year for a > > > FPGA Array Card. > > > > > > The choices have been narrowed down to two families Altera's APEX-II > > > (EP2A70) and XILINX Virtex-II (XC2V6000). > > > > > > Which can operate at the highest speed? > > > > > > Steve > > > > -- > > Posted via Mailgate.ORG Server - http://www.Mailgate.ORG > > -- > ___ ___ > / /\ / /\ > / /__\ Russell Shaw, B.Eng, M.Eng(Research) / /\/\ > /__/ / Victoria, Australia, Down-Under /__/\/\/ > \ \ / \ \/\/ > \__\/ \__\/ -- 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: 39721
Actel's FPGA can be programed only once, or it's prom can only be programed only once, but Xilinx's new part, such as spartan 2, can use a flash to program the fpga, if you don't have much experience in fpga design, I support you'd better not use actel's device for your first design!Article: 39722
rickman wrote > Ray, > > I would like to draw on your experience if I can. I am looking at doing > a SDRAM and SBSRAM interface in an XC2SE chip and would like to get an > idea of what speed grade I will need. Turns out that the DSP chip will > only support up to 100 MHz on the memory bus so I won't have to push the > speed much. Will this be easy on the slowest speed grade which seems to > be a -6? Since there only seem to be two speed grades at this time, I > don't expect to see that much difference (and no industrial in the -7). > I can't tell from the data sheet as it does not have data for the -7 yet > (even though I can buy the parts). > > From your experience will a 100 MHz SDRAM interface be easy in a > XC2S200E-6 ? Depends on how much pipelining is allowed. It would be easy for Ray :)Article: 39723
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:3C6F5581.B301EA21@yahoo.com... > I am from the static timing analysis school. If you keep your design > synchronous and don't use any "tricks", you will find that static timing > analysis will check your design 100%, provided that you specify your > timing constraints correctly. Correct timing constraints are the main > fly in the ointment for this process. The vendors have provided good I agree wholeheartedly with Rick's approach of using a well developed set of constraints and static timing analysis to verify that there are no timing issues. A synchronous design approach allows this methodology to work properly. In my experience with FPGAs, I have only once had to do post layout simulation, and it was to verify that what the synthesizer and PAR tool generated was the same as the intention of the source code. It turned out that a tool vendor had to do a very quick fix! Since then I have always been leery about the end result, but I have never been disappointed. They must test these tools to the nth degree in order to verify that the end result is correct. My reasons for not doing post layout simulation are twofold. First, it takes more time. Second, it promotes synchronous design, which also solves other problems. Everyone have a great day! Simon Ramirez, Consultant Synchronous Design, Inc. Oviedo, FL USA
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