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
> Sorry for the delayed response -- I just got off the phone with the > fruit basket place ;-) Awesome! You could probably just get away with sending 3 SPARTAN Extra crunchy apples. Anyways, the reality is XST is suprisingly good for small to medium designs so don't listen to Austin. And yes, we usually use Synplicity. Ricky.Article: 117026
Jim Granville wrote: > and I also frequently use multiple constructs, and pick the best one. > > $IFDEF VesionCom > Code = here # there; > $ELSE > Code.d = here # there; > $ENDIF > > Try that in Viewlogic ? :) > > Then we come to tool control: I can feed commands to the fitter, from > CUPL source, - how do you do that from Viewlogic ? > > Simulation ?: Also in the same editor. How do you enter/view simulation > data, with Viewlogic ? - and another reference data point, FYI, to compare with your present design flow, is the compile/build/fit time: This design is fully rebuilt, ready to download, in ~1.0 seconds. The editor can be set to silently reload changed files, and remembers the cursor XY, so it is not unlike a browser refresh in speed/convenience. Interested in how that compares with what you have now ? -jgArticle: 117027
steve.lass@xilinx.com wrote: > No, this is not the official Xilinx position. XST is critical to our > business and we > have a strong, dedicated team working on it. In addition, there are tens of > thousands > of happy customers using XST in real designs. We work very closely with our > Synthesis partners (Synplicity and Mentor) and usually recommend that > customers > have access to more than one synthesis tool because no one tool works the > best for > all designs. > > Yes, we realize that there are some language support issues and we are > working on > addressing them. Most have pretty easy workarounds and the ones that don't > get > prioritized higher for being fixed. > > The web page Austin refered to is at least 5 years old and I am personally > going to > make sure it is changed to reflect our current position. Thanks Steve, - can you comment on the relative effort/quality of the HDL branches for VHDL/Verilog/Abel(CPLD), and the long term plans for the XST Simulator (relative to Modelsim et al ) ? -jgArticle: 117028
Dmitry Teytelman wrote: > On Wed, 21 Mar 2007, John_H wrote: > >>> NET "clkp" TNM_NET = FFS(*) "clkp"; >>> TIMESPEC "TS_clkp" = PERIOD "clkp" 3.8 ns HIGH 50 %; >> >> Get rid of the FFS(*) and see what happens. >> >> The BlockRAM specifically needs RAMS(*) if you're trying to keep other >> elements such as multipliers and latches off the timing specification. >> I usually end up with something like >> >> NET sysClk TNM_NET = sysClk; >> >> to specify my main clock. In this syntax it applies to all sequential >> elements. > > John, > > Thanks a million! Of course that was it, now everything runs fine up to > 325 MHz. And my earlier (working) version did not have FFS(*). That is > what happens when you try to get rid of unimportant warnings :( Would the unimportant warnings in question happen to be the one about PAR/MAP getting confused between PAD and IOB FFs timing constraints? I am glad I saw this thread because I was about to make the very same mistake to get rid of those warnings too!Article: 117029
MM wrote: > > I believe only paying customers can create webcases... I only use the free tools, and I've never had a problem opening webcases. -JeffArticle: 117030
Hi There! I did start a post earlier with the title " Digital AM/FM Receiver", and I'm starting one again in continuation to that (the reason for starting another post is selfish....get more visibility....I know...I know...I should be a better person, but I'll wait for next year to make that resolution!!) Anyways, the responses to my earlier post were very informative and with them I've been able to get to a point where I am downconverting from IF (thanks for the suggestion Ray), doing decimation (CIC + invSinc filter) and basic lpf to sharpen the band of interest. Now I plan to use CORDIC to demodulate FM. I was reading up on the CORDIC core and it seems that for ATan(y/x) it takes inputs with 1QN and generates phase outputs as 2QN. The output of my LPF is 42 bits wide 2's complement data and that needs to be fed as the X & Y inputs (obviously 1 lpf for I and one for Q), I want to operate the CORDIC with 16-20 bits of input, I was wondering how I should truncate/round. Do I have to convert since the data is already in 2's complement format and if I just truncated....can I just use the upper bits of the lpf output as the input to the CORDIC? Ideas...a*@ kicking much appreciated!! cheers -MArticle: 117031
On Mar 21, 5:04 pm, "Eric Crabill" <eric.crab...@xilinx.com> wrote: > I don't know of a comprehensive resource exists (if someone else does, > please share!) > > There are some Xilinx application notes that discuss it; most are very > specific to a particular interface. This is the most general I could find:http://www.xilinx.com/bvdocs/appnotes/xapp259.pdf > > I also stumbled across this, which I found interesting reading: > > download.intel.com/education/highered/signal/ELCT762/Class03_Signal_Parameters_II.ppt > > Eric > > <FPGAEngin...@gmail.com> wrote in message > > news:1174515000.274989.98920@n76g2000hsh.googlegroups.com... > > > Thanks for the link! I think I'm mainly looking to be at a point > > where I would feel comfortable doing some initial timing analysis on > > an FPGA I/O interface such as SPI-4 or DDR2, or perhaps something > > system synchronous. Do you know of any detailed examples of where > > this might be done so I can get a feel for it? I'll leave most of the > > internal analysis to the software tools I think. =) Maybe this helps http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?iLanguageID=1&category=&sGlobalNavPick=&sSecondaryNavPick=&multPartNum=1&sTechX_ID=rw_tim_closure_61iArticle: 117032
ZHI wrote: > On 21 Mar, 15:58, "Daniel S." <digitalmastrmind_no_s...@hotmail.com> > wrote: >> ZHI wrote: >>> I have to generate a block ram in xilinx. The data width is not fixed >>> and it will be changed according to the requirement of project. I have >>> noticed that the data width in the block ram has been designed to be >>> the 2's exponential size. Sometimes the data width I needed was not >>> exactly the 2's exponential size. Is there a way to make the data >>> size not the 2's exponential size exactly? Like 18bit width. >> Available widths are 1,2,4,8,9,16,18,32 and 36bits - 9, 18 and 36bits >> widths are achieved by using parity bits. >> >> To achieve high speeds and and area efficiency, BRAMs are built as SRAMs >> and come with similar row-column organization that places some restrictions >> on how freely bits can be accessed. If you use 8, 16 or 32 bits, you waste >> the parity bits. If you use 9, 18 or 36bits, you can use every bit within >> the BRAM. For any other width not listed in the first paragraph, you will >> be wasting bits up to the next widest width. > > -------------------------------------------------- > Thanks. But Xilinx2P doesn't support this function, does it? I found > it in Xilinx-4/5 Huh? The V2P's BRAM design has been inherited by the Spartan 3 and Virtex 4... the only difference is that the V4 adds read-before-write, byte enables on writes and wraps BRAMs in an optional (and quirky) FIFO hard-macro. Other than that, they are all practically the same. The V5 BRAMs push BRAM capacity to 36kbits (but can still be operated as two completely independent V2P/S3/V4-like halves), add support for 64/72bits widths, ECC and fully functional (no known quirks yet) FIFO hard-macros. XST does not support inferring BRAMs with asymmetric port widths but this can be worked around of by using direct instantiation, you just need to find the necessary entity name and port map. If all you want is a BRAM with all same-width port, simply lookup XST's coding style guide for the coding templates. I have done it many times with ISE 8.1/8.2 and have been mostly successful.Article: 117033
Hello Daniel, On Thu, 22 Mar 2007, Daniel S. wrote: > Would the unimportant warnings in question happen to be the one about PAR/MAP > getting confused between PAD and IOB FFs timing constraints? I am glad I saw > this thread because I was about to make the very same mistake to get rid of > those warnings too! I added FFS(*) to the constraint to get rid of the following warning in the translation report: WARNING:XdmHelpers:662 - Period specification "TS_clk_ctrl_aclk4_dcm" references the TNM group "clk_ctrl_aclk4_dcm", which contains both pads and synchronous elements. The timing analyzer will ignore the pads for this specification. You might want to use a qualifier (e.g. "FFS") on the TNM property to remove the pads from this group. -- Dmitry TeytelmanArticle: 117034
On Mar 21, 5:22 am, Herbert Kleebauer <k...@unibwm.de> wrote: > This is an exercise to a lecture about computer organization. The student > have just learned how to make a truth table, minimize logic functions and > design simple state machines. In this exercise they should use this > knowledge to implement a little bit more complex design. And what > can be more interesting than designing your own CPU. Therefore VHDL > isn't any alternative, they are only allowed to use D-FF's and simple > gates like AND,OR,NAND,NOR. Since when does VHDL not have AND, OR, NAND, NOR, and D flip flops? Perhaps the problem is that it has a lot more than these. But the solution is also simple: make rules about what they are allowed to use. Provide a preprocessor or audit tool that will enforce this - the only thing you are allowed to do is instantiate these allowed basic entities and hook them up with plain wires and vectors. > We could stop the course after simulating > the design, but it is much more motivating when at the end your CPU > is running in hardware. But this hardware has to be a simple hardware > (not one of this complex multilayer FPGA prototyping boards) so they > see that there is no hidden technology and they even could make the > same board at home with an cheap soldering iron. But the fact of the matter is that there is hidden technology at all levels of the system. As has been pointed out, the tools don't implement the actual gates you've drawn, they implement a logical equivelent. And there's also sorts of hidden semi-proprietary stuff on the FPGA die. You may find this easier to ignore with an older part, but it's still true. Unless you go back to very raw TTL type chips (or maybe even earlier), what your students will be designing with is a black box abstraction that _does not really match_ its logical symbol representation except in explicit ways the data sheet says it does. Is this an engineering major's course or some sort of survey thing?Article: 117035
"Duane Clark" <junkmail@junkmail.com> wrote in message news:aITLh.15$rO7.4@newssvr25.news.prodigy.net... > Ken Soon wrote: > > ... > > Yeh for the hardware multipliers, I guessed it automatically changed the > > DSP48s to the multipliers, but alas, shortage problems again. 60 mulitpliers > > needed for 36 available. > > Analyze the design a bit; 60 multipliers sounds like a lot, though I > have not done video work. Maybe you don't need all of them, or maybe > some are being used to multiply small numbers that could be handled in > LUTs. If some of the multipliers are only doing a multiply every 2 or 3 > or 4 clocks, maybe some could be shared. That's a good idea of sharing the multipliers. Hmm I just have to figured out though. I will be using the DRAM controller found on the Xilinx website since I am working on the Spartan 3E, make things a little less tricky, ya. Well I am spanking brand new to FPGA design though unless you wanna count just simply grabbing simple designs from the net to configure the Spartan 3E starter kit. Yep definitely, months of "fun" ahead of me.Article: 117036
> I've mostly done Verilog in ISE but just now I'm attending a VHDL- > course at a university and they use Altera's QuartusII tools. They > also include Multi-CPU-support and at least it is possible to select > how many of your CPU's that will be used from QuartusII. Can anyone > comfirm this? Is the SMP-support in Alteras QuartusII better that the > non-existant in Xilinx ISE? My project has been so small so I can't > measure any difference! :-)- Quartus II 6.1 (and later versions) are parallel programs -- Quartus will use multiple CPUs to speed up a compile if you tell it you have multiple CPUs available. See http://www.altera.com/literature/hb/qts/qts_qii52005.pdf (page 8-85) for details on how to tell Quartus how many CPUs you want it to use. In QII 6.1, the speed-up for two processors is typically 10% for fitting and timing analysis, and about 15% for four CPUs. The algorithms we have parallelized have sped up quite well -- about 1.6X to 1.9X speed-up on two processors, but only some of the major algorithms are parallel at this point. We are working to parallelize more algorithms, so expect these numbers to increase in future Quartus releases. The Quartus results (synthesis, fit, timing analysis, and programming file) are identical regardless of how many CPUs are used during the compilation. Another way Quartus makes use of multiple processors is with the Design Space Explorer (DSE) utility. DSE runs Quartus multiple times with different optimization settings to look for the fastest, smallest, or lowest power (your choice) implementation of your design. If you have multiple CPUs or multiple machines available, DSE can run these Quartus compiles in parallel. See http://www.altera.com/literature/hb/qts/qts_qii52008.pdf for details on DSE. I expect parallel features will become ever more important as multi- core CPUs proliferate. Today dual-core is common. Intel and AMD have made it clear that within a year you'll get a quad-core processor for little price premium over today's dual-core CPUs. And that's unlikely to be the end of it. Regards, Vaughn AlteraArticle: 117037
Thanks Steve (and also Austin) for clarification. The original comment would have been hard to believe. So there is still hope that things are going to improve... Thomas <steve.lass@xilinx.com> schrieb im Newsbeitrag news:etsfct$kuu1@cnn.xsj.xilinx.com... > No, this is not the official Xilinx position. XST is critical to our > business and we > have a strong, dedicated team working on it. In addition, there are tens > of thousands > of happy customers using XST in real designs. We work very closely with > our > Synthesis partners (Synplicity and Mentor) and usually recommend that > customers > have access to more than one synthesis tool because no one tool works the > best for > all designs. > > Yes, we realize that there are some language support issues and we are > working on > addressing them. Most have pretty easy workarounds and the ones that don't > get > prioritized higher for being fixed. > > The web page Austin refered to is at least 5 years old and I am personally > going to > make sure it is changed to reflect our current position. > > Regarding why students cannot enter webcases, I believe this the main > reason: We > are using the professors to filter out bad coding techniques and questions > like how > do I create a state machine or how do I design a chess game in an FPGA. > > Steve > > > "Thomas Entner" <aon.912710880@aon.at> wrote in message > news:46014d7e$0$25619$91cee783@newsreader02.highway.telekom.at... >>> In other words, XST is a test vehicle where we are intentionally >>> experimenting, in order to improve. >> >> Hi Austin, >> >> is this your personal meaning, or official Xilinx? Do the >> Xilinx-software-team see their work in this context? Does this mean, that >> XST and/or ISE should not be used for serious work? >> >> Thomas >> >> > >Article: 117038
Austin Lesea wrote: > Jim, > > I quote: > > "Q: How extensive is XST language coverage? > A: With each release, XST is closing in on the de facto coverage set by > other synthesis tools. Xilinx estimates the current language support > covers at least 95% of the constructs supported by other synthesis > tools. Many of the unsupported constructs are infrequently used or have > simple work-arounds. Also, many of these constructs are not handled > consistently by each synthesis tool. For example, one tool accepts a > construct in one way, another tool accepts the construct in a different > way, and a third tool flags a parsing error. In some cases, XST is more > precise than other tools, and requires exact, complete descriptions > while other tools accept incomplete or vague code. These are common > considerations when moving code from one synthesis tool to another." > > This was written in 2001, and I am told that we are much better now, but > still not 100% of what is covered by the commercial tools. > > As for the software group, they have contacted me. And we have talked > this over. > > They are very proud of their tool, and find this thread troubling. They > would not characterize their tool as "experimental," but as a > world-class synthesis tool, examining limitations that other tool > vendors have. Their tool provides value to many (most), and is probably > more widely used to synthesize logic from HDL than any other tool. > > Austin I have been a xilinx user for about 16 years and would like to comment on this and the companion threads. The early xilinx software was beyond awful. You had to reboot the computer after each run--if you were lucky enough for it to finish. By ISE6.3, the system was pretty good and I was happy with it. Since then, it has been mostly downhill. Version 7 was a major step backwards and whoever did the programming clearly never used the system. It became very slow and very ackward. For me, versions 8.1, 8.2 and 9.1 are disasters which will not process my designs. I have some legacy schematic designs which I am converting to vhdl. Version 8.1 just blew up on them. Version 8.2 would import the project but the horrible memory leaks blew up the computer before it would finish xst. Version 9.1 was the same. So there were three releases and 10 service packs which did not work. The software testing now seems to be that if it compiles that is good enough. It is clear that they have not tested a schematic program for around two years. I have been told that they expect things to work in version 10.0 next year. All of that said, I think xilinx deserves some slack. When it works, ise is really quite good for the price. It is slow and has issues but it lets you do a lot. Xilinx has also been responsive (but generally not useful) on webcases. The suport people seem to care but they do not get the support they should. I will say that, after an earlier thread on sofware issues, they made an attempt to make the schematics work. They sent me some fixes that helped enough on the memory leak to uncover two other fatal bugs. The first is that xst attempts to use the .ucf pin assignments on all the submodules and blows up because, of course, they do not have the pins of the top module. If you get rid of the .ucf file and let it do what it wants, it blows up on the other fatal bug in that it does not know how to find libraries. I do not know what other bugs there are but from this, it is obvious that they never actually tried to process a schematic design. I am optimistic that things will get better. Perhaps this is a try to get me to convert the designs to vhdl sooner rather than later even though I am an old man who really prefers to see the design than to wade through pages of code which one writes hoping that vhdl will see it your way and instantiate what you want. In schematics, you put in what you want and there it is. All the threads on "why does vhdl give me latches instead of flip-flops or distributed ram instead of blockram etc" seem odd to me. I also would like to say again that I appreciate the presence of the ever enthusiastic Austin and the ever patient Peter on the newsgroup.Article: 117039
On Mar 21, 8:40 pm, j...@zilium.de wrote: > On Mar 21, 1:15 pm, Rem...@gmail.com wrote: > > Hi all, > > > Yes Lattice Mico8/Mico32 are open source, but can you really use them > > anywhere else except only with Lattice ISP Lever and Lattice FPGA > > devices??? > > Yes, you can. > > I'ts running on my Spartan-3E starter kit and I'm currently porting it > over to the > Altera Cyclone-II Starter kit. > > I don't have it integrated into the Eclipse IDE Lattice is shipping -- > but at least I've > got theCPUrunning in my own wishbone based SOC. > > Having the source for all components available feels quite good for > me. And it's cross-platform. > I won't go back to MicroBlaze in the foressable future. > > j. >>-jg >>Is that an Altium user talking, or the PR spin on a sales brochure ? I am just Altium User and I love the tool for sch capture, layout, SPICE and signal Integrity Analysis. haven't jumped on it with FPGA develpments. So far I've been using Xilinx ISE. > I'ts running on my Spartan-3E starter kit and I'm currently porting it > over to the > Altera Cyclone-II Starter kit. you really got my attention on Mico32, since my target hardware is Xilinx. How is performance running on Xilinx Spartan3, what clock frequency can you push it to. And thanks for clarifying this. I always thought that Lattice Mico32 is like Microbalze, with code tailored for specific architecture. Well I guess then it was one unselfish move from Lattice point of view :) Just have read that uClinux is in the process of being ported to Mico32. This open source project could really take off.Article: 117040
Maybe I got something wrong=EF=BC=8EI want to use a double port ram. I sele= ct a BRAM in the core generator. It looks like everything can be generated automatically. I did not find the parity bit. Am I wrong? On 22 Mar, 00:09, "Brad Smallridge" <bradsmallri...@dslextreme.com> wrote: > Have you seen or used the inferred RAM/ROM in the Xilinx Toolbox? > > "ZHI" <threeinchn...@gmail.com> wrote in message > > news:1174471565.885982.284820@y66g2000hsf.googlegroups.com... > > > > >I have to generate a block ram in xilinx. The data width is not fixed > > and it will be changed according to the requirement of project. I have > > noticed that the data width in the block ram has been designed to be > > the 2's exponential size. Sometimes the data width I needed was not > > exactly the 2's exponential size. Is there a way to make the data > > size =C2=A0not the 2's exponential size exactly? Like 18bit width. > > > Thank you.- Hide quoted text - > > - Show quoted text -Article: 117041
> The Lattice Mico32 is pretty cool especially since it has a Wishbone > bus. I haven't looked, but I've been told the Mico32 is written in > behavioral VHDL. It's written in Verilog. The only Lattice specific code in the CPU is in the debug unit, as that makes use of the Lattice JTAG hardware block. Cheers, JonArticle: 117042
On Mar 22, 9:21 am, Rem...@gmail.com wrote: > > I'ts running on my Spartan-3E starter kit and I'm currently porting it > > over to the > > Altera Cyclone-II Starter kit. > > > I don't have it integrated into the Eclipse IDE Lattice is shipping -- > > but at least I've > > got theCPUrunning in my own wishbone based SOC. > I am just Altium User and I love the tool for sch capture, layout, > SPICE and signal Integrity Analysis. > haven't jumped on it with FPGA develpments. So far I've been using > Xilinx ISE. Never used Altium -- can't comment on that. My workflow is far from nice. Although there are wishbone system builders (Counting the Lattice IDE as one of them), my workflow for Xilinx ISE and Altera Quantus still heavily depend on cut'n paste. > > I'ts running on my Spartan-3E starter kit and I'm currently porting it > > over to the > > Altera Cyclone-II Starter kit. > > you really got my attention on Mico32, since my target hardware is > Xilinx. How is performance running on Xilinx Spartan3, what clock > frequency can you push it to. On my XC3S500E-4 I get between 90 and 95 MHz -- with default XST/PAR options. So I'd expect 100MHz to be the limit. Takes < 1500 LUTs. I'll publish my ISE project as soon as I fixed some problems with the DDR controller. But that won't be before ~10 days. Porting the actual CPU is trivial -- only some small changes to make XST happy. > And thanks for clarifying this. I always thought that Lattice Mico32 > is like Microbalze, with code tailored for specific architecture. Well > I guess then it was one unselfish move from Lattice point of view :) LM32 ist straight-forward verilog RTL code. > Just have read that uClinux is in the process of being ported to > Mico32. This open source project could really take off. Hope so. Having a mutually compatible set of OSS hard- and softwarecomponents whould be really great -- and could bring a boost to reconfigurable hardware. Sad, that there's no OSS toolchain for synthesis and par :( Or at least a common build system where different verndor tools could plug in. Changing your FPGA vendor is still too much pain. j.Article: 117043
Austin Lesea wrote: > InmateRemo, > > Thoughts to share: > > I would suggest that Xilinx is the only provider with a continuous > history of providing a code compatible (MicroBlaze) soft processor. > > Where others had their first version (which did not work very well) and > then abandoned it (leaving all their customers with useless code). > Xilinx recognizes that to be a serious player in the embedded processor > space there must be backward compatible code (forever). Intel's rule is > very simple, you can research and play with any architecture you wish, > but there is one, and only one instruction set (x86). > I can't really comment on the MicroBlaze, having never used it, but I've used large numbers of processors in embedded systems over the years. And if there is one thing I know about object code compatibility, it is that it is vastly overrated. There are only a few situations where object code compatibility is important. One is when you are replacing an obsolete part with a new part, and are trying to avoid development costs. That requires absolute 100% compatibility in hardware and software. You don't get that in the fpga world (your new part will have different footprints, power supplies, etc., and will need a re-build of the fpga design). Second is when you have old assembly code that must be re-used - that's mostly an issue for 8-bit microcontrollers. Third is for when you are using third-party binary-only software modules. That's mostly an issue for windows pc's. Finally, the only issue that is at all relevant in this case, you sometimes have short code sections that are hand-written in assembly for very low level tasks, or for specialised optimisations. Adapting these to a new processor ISA is seldom a major part of a port. Source code compatibility is, of course, vital. But that's a matter of sticking to your favourite C standard and structuring your core-specific functionality (such as interrupts) properly. Transitioning between a Nios and a Nios II, for example, is little more than a re-compile on the software side. Clearly you don't break the ISA unnecessarily. But if it is a major problem for your customers when the MicroBlaze II is object-code incompatible with the MicroBlaze, then your tools are not good enough. When there is enough benefit to be gained from a change in ISA, you make that change. The x86 is an example of *exactly* why you must be able to change the ISA. Modern x86 cpu's are fantastic implementations of a terrible design, with vast amounts of time and effort spent to make such a rotten ISA work well in practice, demonstrating that you can, in fact, polish a turd. > In a similar fashion, we have PicoBlaze (still the KCMP core from long > ago), MicroBlaze (32 bit Harvard architecture soft core optimized for > our architecture -- unchanged as far as instructions from day 1), and > the IBM Power PC family (405, 4??, ???: the roadmap being IBM's "power" > architecture roadmap, just delayed). > > With as many customers as we have, with all of their designs, and as > many seats of software (more than 250,000 installed), and our long > history (invented the FPGA in 1984), besides our business position (took > PowerPC(tm IBM) architecture from ~33% in embedded systems when we > introduced Virtex II Pro, to more than 50% of embedded systems today); > you would be well served to stick with Xilinx. > > AustinArticle: 117044
cs_posting@hotmail.com wrote: > On Mar 21, 5:22 am, Herbert Kleebauer <k...@unibwm.de> wrote: > Is this an engineering major's course or some sort of survey thing? These are not electrical engineering but computer science students. Their job will be to design software and not hardware systems. But in order to do a proper software design, you need to understand the principles of the underlying hardware so you get a feeling what a few lines of HL code can mean for the hardware. I don't know if all the supporters of VHDL/Verilog/HandleC here have done low level logic development using a graphical representation and just don't recognize how important that is to become a good designer at VHDL level or if they have never done this and still think they are good developers because the VHDL compiler is good enough and therefore they don't need to know anything about lower levels. Again the city map is a good example: If you want to drive from A to B, you call a taxi, the driver enters the target into the navigation system and this system mostly does a much better job you could do with the city map on your lap. So this is the best you can do if you know nothing about the city. But if you know the layout of the city and you know that there is a river with only two bridges where you have to wait a long time because of the high traffic and you also know that there is a small bridge which could only be passed by foot, then you could do a much better job by driving to the small bridge, cross the river by foot and use an other taxi on the other side. The same is true for software: if you know how the hardware works you maybe can choose a different approach to solve the problem which is much more appropriate for the hardware. The compiler can do local optimizations extremely good, but the best global strategy has to be chosen by the programmer. And I think the same is true for hardware design. Just writing down VHDL statements without understanding the consequences for the generated hardware is not the way to go. The purpose of Universities is not to teach the students the use of tools but to teach them how to recognize, analyze and solve problems. The tools you use to solve the problems change rapidly but the ability to understand the source of a problem and analyze it from all angeles without using blinders is an essential requirement for the whole life. And as I said in the original posting, replacing the schematic entry by VHDL/Verilg isn't an alternative. All I wanted to know is, if somebody already was able to run the old Vielogic (DOS) on an actual OS (using a virtual machine). Or, whether there exists new FPGA's with a development system which is as easy to use as Viewlogic/DOS _AND_ where the chips are available in a package which could be soldered with a normal soldering iron on a self made non-multilayer PCP. I think there are both things available, but I didn't find the _AND_ combination. > > We could stop the course after simulating > > the design, but it is much more motivating when at the end your CPU > > is running in hardware. But this hardware has to be a simple hardware > > (not one of this complex multilayer FPGA prototyping boards) so they > > see that there is no hidden technology and they even could make the > > same board at home with an cheap soldering iron. > > But the fact of the matter is that there is hidden technology at all > levels of the system. As has been pointed out, the tools don't > implement the actual gates you've drawn, they implement a logical > equivelent. Sorry, but it really doesn't matter whether the AND gate is implemented as AND gate, by multiplexers or as a look-up table. They have learned that this all is equivalent and that the order of complexity is the same. But they must learn that there is big difference in the complexity for the ALU operation "add" and "div" and they don't see this in the VHDL source code.Article: 117045
On Mar 21, 11:48 am, "Pasacco" <pasa...@gmail.com> wrote: > Dear all > > I am trying to manually map "2-bit AND" function into single slice, > with no luck -: > > I type the commands below in the FPGA editor. > > Problem is that, > > "F" port of slice is NOT connected to "D" pin of LUT. > > I wonder if following is correct. > > F:\#LUT:D=A1\*A2\ > > If someone has experience, let us know how I should modify the > command. > Any document or pointer will be also grateful. > > I am using ISE 8.2.03 and Virtex-4. Thank you in advance. > > -------------------------------------------------------------------------------------------------------------------------- > select site "SLICE_X0Y2" > add > setattr comp $COMP_0 Name s0 > unselect -all > > select site "SLICE_X2Y2" > add > setattr comp $COMP_1 Name s1 > unselect -all > > select comp "s1" > setattr comp s1 F A1*A2 > setattr comp s1 G A1*A2 > > setattr comp s1 Config COUTUSED:\#OFF\ YUSED:0\ XUSED:0\ F5USED:\#OFF\ > YBMUX:\#OFF\ YINIT:\#OFF\ > F:\#LUT:D=A1\*A2\ REVUSED:\#OFF\ SYNC_ATTR:\#OFF \ SRFFMUX:\#OFF\ > FFY_SR_ATTR:\#OFF\ FFX:\#OFF\ FFY:\#OFF\ FFX_SR_ATTR:\#OFF\ G_ATTR: > \#OFF\ DIG_MUX:\#OFF\ CY0G:\#OFF\ FXUSED:\#OFF\ DIF_MUX:\#OFF\ F_ATTR: > \#OFF\ CY0F:\#OFF\ DIGUSED:\#OFF\ SHIFTOUTUSED:\#OFF\ BYOUTUSED:\#OFF\ > FFX_INIT_ATTR:\#OFF\ FFY_INIT_ATTR:\#OFF\ > .... > -------------------------------------------------------------------------------------------------------------------------- You will see the connections turned (in light blue) from the LUT inputs to the LUT if you have nets driving the inputs outside the slice. So you need to add two nets and connect them to the F1 and F2 inputs. HTH, Jim http://home.comcast.net/~jimwu88/tools/Article: 117046
when I download bitstream to Xsa3s1000 board by impact (I load p3jtag.svf file to CPLD by GLoad and setting jump as the instruction from Xess before) it run ok.But when i plug Xsa3s1000 to XST3.0 extent board , i can't download the bitstream by impact, the error is "CRC check error".is there any one can help me to solve this problem.Thanks a lot!Article: 117047
Herbert Kleebauer wrote: > Jim Granville wrote: >>What are the prime teaching targets: learning FPGA flows, or >>learning shematic entry ? > Nothing of both. The goal is, to use a handful of FlipFlops and > gates to implement a design for which you only get the specification. > It's just a replacement for a prototyping board with many TTL gates. I will assume this is for an undergraduate frosh level course, adjust as appropriate. When I took such a course, it was in the days of 74LS series logic. I even remember learning that the 7474 has a positive hold time, but 74LS74 has zero hold time. As I understand it, many such courses are now taught using only simulation. (snip) > That's like a city map which doesn't use graphics but only > textual description of the street position and connections. > You will never get a feeling for the layout of the city > whereas a fast glance on the graphical city map shows you > all. Sure, if you use one of the modern navigation systems > you don't need any overview of the city, you are told > when to turn left or right. This may be is the best way > if you only want to go from position A to position B, > but if have to understand how the city is organized, then > this is completely inappropriate. I try to write structural verilog (except for FF's), which tends to have more of the feel for the logic layout than behavioral verilog. (Also, I believe it is more readable than VHDL but that's a different question.) Assuming you believe that eventually it is better (as projects get larger) to use HDLs, is it better to start earlier? -- glenArticle: 117048
Herbert Kleebauer wrote: (snip) >>ALU = s7 & !(XGate # YGate) >> # !s7 & (XGate $ YGate); /* Dummy, until adder done */ > How should the student get a feeling how many gates are necessary > to implement this two lines? It's the same as programming in a > HLL. No question, it is much more effective to us a HLL than > using an assembler. But any HLL programmer should have done > assembly programming so he has a feeling what a HLL code > snippet has for consequences for the CPU and so he not always > selects the code which is most easily written but the code which > most easily can be calculated by the CPU. My belief is that one should always understand the system one level below that which one is using, so yes HLL programmers should understand assembly programming. I don't believe that means one should learn assembly programming first, though. Even so, a lower level HLL like C tends to be pretty close in the number of operations compared to the amount of C code. In both cases some operations take more time than others, and one has to learn that eventually. Both HDL and schematic capture can be done using library modules that are simple or complex, in pretty much the same way that either assembly or C can call complex system macros or library routines. -- glenArticle: 117049
Dmitry Teytelman <dimtey@moc.liamg> writes: > Hello Daniel, > > On Thu, 22 Mar 2007, Daniel S. wrote: > >> Would the unimportant warnings in question happen to be the one >> about PAR/MAP getting confused between PAD and IOB FFs timing >> constraints? I am glad I saw this thread because I was about to make >> the very same mistake to get rid of those warnings too! > > I added FFS(*) to the constraint to get rid of the following warning > in the translation report: > > WARNING:XdmHelpers:662 - Period specification "TS_clk_ctrl_aclk4_dcm" > references the TNM group "clk_ctrl_aclk4_dcm", which contains both > pads and synchronous elements. The timing analyzer will ignore the > pads for this specification. You might want to use a qualifier > (e.g. "FFS") on the TNM property to remove the pads from this group. > I reckon that warning ought to end with "... but you probably don't as this might break all sorts of other things unless you really understand what this does" :-) Xilinx: How about a) A better warning b) the ability to say "NOPADS" on the TNM property (or NOFFS, NORAMS etc...) Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.html
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