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
cs_posting@hotmail.com wrote: > On Nov 14, 9:46 am, Herbert Kleebauer <k...@unibwm.de> wrote: > >> Sadly the same can't be >> said about the current Xilinx software (schematic editor + simulator), >> so we will try to stay as long as possible with the X3000 chips and the >> old Xilinx DOS software (with ViewLogic schematic entry + simulator). > > The real problem is your insistence on using schematic entry for > things of moderate complexity. > > Learn a hardware description language and your life will be much > easier. ... and after knowing your configuration, use a Makefile to run implementation and say good bye to the gui. http://www.dilloneng.com/documents/downloads/gen_ise_sh/ Cheers, GuenterArticle: 126076
I am pleased to have such a positive response to one of our products. I am also pleased to say that as of this week Rev1.1 is shipping to customers. The major change is the programing headers are changes to 2x7 2mm headers compatible with our own Prog2 cable and all of the Xilinx cables with 2x7 ribbon cable. We also now have a limited stock of Darnaw1 with XC3S1600E and XC3S1200 (I GRADE) fitted. They are not on the shop website as yet but are available to anyone that needs the different variants. Pricing etc are listed on our enginering web pages. I would also welcome any feedback on Darnaw1 from anyone that has seen the product as we prepare to start the Darnaw2, and maybe even the Darnaw3, designs. These wouldn't replace Darnaw1 but will cover slightly different application areas albeit with the aim of a compatible footprint within the product family. John Adair Enterpoint Ltd. On 14 Nov, 14:46, Herbert Kleebauer <k...@unibwm.de> wrote: > A few month ago I asked for a recommendation for FPGA (not a ready to use demo board) > which could be handled with simple home equipment. I got the link to: > > http://www.enterpoint.co.uk/moelbryn/darnaw1.html > > We ordered a few samples and did some experimenting. Here the documentation > for a simple 16 bit CPU implemented on the DARNAW1. It includes also a step by > step introduction which should allow anybody still unfamiliar with FPGA design > to implement the demo in less than a hour. > > ftp://137.193.64.130/pub/mproz/mproz3_e.pdf (documentation)ftp://137.193.64.130/pub/mproz/mproz3.zip (documentation + schematics) > > Conclusion: > The board is great, not just an other demo board, but rather a package > converter from the FPG ball grid to a pin grid array with the necessary > voltage converters and program flash on board. Sadly the same can't be > said about the current Xilinx software (schematic editor + simulator), > so we will try to stay as long as possible with the X3000 chips and the > old Xilinx DOS software (with ViewLogic schematic entry + simulator).Article: 126077
>The real problem is your insistence on using schematic entry for >things of moderate complexity. > >Learn a hardware description language and your life will be much >easier. I'd agree with that, as practical advice. Long-term, perhaps we'll expect better graphical tools. We have text-based languages now partly because they are easier to define accurately and because they exploit our familiarity with complex text written in linear fashion (over several pages), so it's a practical way to keep a complex design under control and to write it down. We don't (yet) have comparable graphical tools, but perhaps that will come. I'm not sure the Mona Lisa would be as good if Leonardo had made it with a text-based graphics description language or that Beethoven's Fifth Symphony has the same appeal when experienced as a hex dump of the WAV file.Article: 126078
Amal, An unencrypted bit file is 3 to 7% 1's (97 to 93% 0's) typically. An encrypted bit file is roughly 50% 1's and 0's. Real easy to tell them apart. AustinArticle: 126079
Hello, I am in some way a newbie in getting things to run on an FGPA, so I would be helpful if someone could help me a little bit out how to get started. I have implemented a simple processor architecture in VHDL and I successfully simulated it with Modelsim. Now my next goal would be to get this processor running on a Xilinx Virtex-II PMC FPGA board. For synthesis I am going to use Xilinx ISE 7.1i. So to see if the processor on the FPGA is doing what it should do I could use Chipscope and the Jtag interface. However, I am a little bit lost with the following tasks. 1) I had some kind for simple RAM for simulation. How can I implement this RAM correctly so that it be sythesizable and will correctly run on the FPGA? 2) When I start the processor, I should have my instructions loaded into the Instruction RAM? How can I do this, really no clue :( I am sorry for these basis questions, but I would be thankful if someone could give me a hint where and how to start! Many thanks!! AndiArticle: 126080
> 1) I had some kind for simple RAM for simulation. How can I implement > this RAM correctly so that it be sythesizable and will correctly run on > the FPGA? > > 2) When I start the processor, I should have my instructions loaded into > the Instruction RAM? How can I do this, really no clue :( I am just reading the XST userguide. There it says that with version 8.1i it is possible to directly specify data with the RAM module or load it from an external source. IN addition it says the multiple write ports in the RAM are supported from version 8.1 on. UNfortuantely I just have version 7.1 and I should have a RAM that has 4 read ports and 2 write ports? Is that somehow to realise with ISE 7.1 or do I need to upgrade to version 8.1? Many thanks, AndrewArticle: 126081
Hi,
I have a question about Xilinx post-P&R static timing reports. I
understand most of the constraints listed in the timing report, but
some of them don't appear in my UCF and have me a bit confused.
Could anyone tell me what the time groups J_CLK and U_CLK are and why
they are configured this way? I can't find any mention of these in
the documentation. I've attached a bit of my .twr to the bottom of
the post. I've seen them in several project so my guess is that they
have something to do with using chipscope or that these are the names
of some sort of global clock net.
Thanks in advance,
Peter
--------------------------------------------------------------------------------
Constraint | Requested | Actual
| Logic
| |
| Level
--------------------------------------------------------------------------------
TS_J_TO_J = MAXDELAY FROM TIMEGRP "J_CLK" | 30.000ns | 11.588ns
| 2
TO TIMEGRP "J_CLK" 30 ns | |
|
--------------------------------------------------------------------------------
TS_U_TO_J = MAXDELAY FROM TIMEGRP "U_CLK" | 15.000ns | 4.473ns
| 1
TO TIMEGRP "J_CLK" 15 ns | |
|
--------------------------------------------------------------------------------
TS_U_TO_U = MAXDELAY FROM TIMEGRP "U_CLK" | 15.000ns | 1.496ns
| 0
TO TIMEGRP "U_CLK" 15 ns | |
|
--------------------------------------------------------------------------------
PATH "TS_U_TO_D_path" TIG | N/A | N/A
| N/A
--------------------------------------------------------------------------------
PATH "TS_J_TO_D_path" TIG | N/A | 6.921ns
| 32
--------------------------------------------------------------------------------
PATH "TS_D_TO_J_path" TIG | N/A | 5.117ns
| 5
--------------------------------------------------------------------------------
Article: 126082Hello all, I would like to use the USR_ACCESS_VIRTEX4 primitive to access an additional bitstream stored in a config flash. The situation is following: * I have a master FPGA (Virtex-4FX) and a slave FPGA (Spartan-3A). The slave FPGA is located on an additional board and it is NOT daisy-chained with the master one. * Master FPGA gets configured out of platform flash in master serial mode. * I need to configure even the slave FPGA. The only non-volatile source of its configuration data is the platform flash connected to the master FPGA. I used STARTUP_VIRTEX4 primitive to take control over the CCLK and DONE signals. While generating bitstream I used the "-g DONE_cycle:KEEP" option. From my measurements of the interface between flash and Virtex-4, this part of the design works fine. I fully control the signals, DONE does not go high anywhere in the middle, and flash sends me additional bitstream data. To access additional bitstream I instantiated the USR_ACCESS_VIRTEX4 primitive, but here is the problem. Even though I see the data on the DIN input of the Virtex-4, the DATAVALID output of the USR_ACCESS_VIRTEX4 primitive never goes high. So that I am unable to reach this data inside the Virtex-4 FPGA. The Virtex-4 Libraries Guide for HDL Design says: The PROM should contain a packet of data with the USR_ACCESS register as the target. I generated my PROM file using iMPACT simply putting two bitstreams into single MCS file what is probably wrong. I think my MCS should contain normal master FPGA bitstream followed by the slave FPGA bitsream with target set to USR_ACCESS. Is there any way how to set target for the second bitsream in MCS to USR_ACCESS so that I could access it from my master FPGA? If I am trying to do something impossible, is there another approach how read slave configuration data from platform flash using master FPGA? I cannot do it simply controlling flash pins, as they are not connected to IO pins of the FPGA but to dedicated configuration pins only. Thanks for advices, JanArticle: 126083
Andrew Ganger wrote: > UNfortuantely I just > have version 7.1 and I should have a RAM that has 4 read ports and 2 > write ports? Is that somehow to realise with ISE 7.1 or do I need to > upgrade to version 8.1? Mixed something up, my Register File should have 4 read ports and two write ports :)Article: 126084
On Nov 14, 10:50 am, MikeShepherd...@btinternet.com wrote: > Long-term, perhaps we'll expect better graphical tools. We have > text-based languages now partly because they are easier to define > accurately and because they exploit our familiarity with complex text > written in linear fashion (over several pages), so it's a practical > way to keep a complex design under control and to write it down. > > We don't (yet) have comparable graphical tools, but perhaps that will > come. I'm not sure the Mona Lisa would be as good if Leonardo had > made it with a text-based graphics description language The problem is that you seem to want to use the graphical layout to represent the wrong aspect of the design. Schmetic level and HDL level entry both try to capture functionality, but HDL level is far superior for managing the the kinds of complexity involved in accomplishing real functionality. If you want to do something graphical, do it at the system level. Use something like Matlab & Simluink to describe what you want the FPGA to do, and then use the HDL generation plugins. to make the FPGA actually do it. The possible case where FPGA-vendor-tool schematic entry might still make sense is if you do all the actual implementation modules in HDL code, but make your top level a system-block-diagram sort of schematic. Otherwise you're just trying to represent in messy pictures what is much clearer in text.Article: 126085
On 14 Nov., 18:23, Peter Klemperer <ftpe...@gmail.com> wrote: Hi Peter, > Hi, > <snip> > I've seen them in several project so my guess is that they > have something to do with using chipscope or that these are the names > of some sort of global clock net. > > Thanks in advance, > Peter > using chipscope, you should see an edif-netlist like "icon.edn" or something like this, that will integrated automatically within your toplevel design running ngdbuild. I guess, you'll find a file called "icon.ncf" within the same directory If you have a look at it's content with a simple editor, you should find said timing-constraints - and they will be automatically linked to your design, too. They are needed to guarantee chipscope's functionality (JTAG- clock,...) hope, it helps, JochenArticle: 126086
What you are asking for is outside the abilities of the Virtex-II FPGA. Since the FPGA only contains dual-ported memories (either SelectRAM-based or BlockRAM-based), there is no possible way to map such a HDL description to the FPGA device. You'll have to figure out a mechanism to multiplex the read/write ports such that you have less than or equal to two ports (be they read, write, or read/write ports). Good luck - welcome to the world of FPGA engineering. - Nathan On Nov 14, 10:02 am, Andrew Ganger <Andre...@yahoo.co.uk> wrote: > Andrew Ganger wrote: > > UNfortuantely I just > > have version 7.1 and I should have a RAM that has 4 read ports and 2 > > write ports? Is that somehow to realise with ISE 7.1 or do I need to > > upgrade to version 8.1? > > Mixed something up, my Register File should have 4 read ports and two > write ports :)Article: 126087
Hi, On Nov 8, 8:43 am, "John_H" <newsgr...@johnhandwork.com> wrote: > "Kryvor" <kris.vorw...@gmail.com> wrote in message > > > (It looks as thoughActelcarries some smaller ProASICPlus parts in a > > TQFP 100 package. Those parts have 2 PLLs and are Flash-based > > [reprogrammable, immune to SEUs, etc.].) > > The Flash cells may be imune to SEUs but the active logic certainly isn't. > SEUs "tend" to be noticed in SRAM cells first but registers are also > affected by the same radiation for FPGAs of any flavor as well as ASICs and > other standard parts. Fair enough. It would have been more accurate for me to say that Actel's Flash FPGAs are immune to configuration loss due to single-event errors. In the interest of thoroughness, Actel's Flash FPGAs *have* undergone substantial FIT testing and are quite resilient (compared to SRAM devices) in terms of their alpha and neutron radiation handling: http://www.actel.com/products/solutions/ser/ cheers, K.Article: 126088
Thanks Jochen, that did it for me. I should have grep'd for it. --Peter On Nov 14, 12:19 pm, Jochen <JFren...@HarmanBecker.com> wrote: > On 14 Nov., 18:23, Peter Klemperer <ftpe...@gmail.com> wrote: > Hi Peter, > > > Hi, > > <snip> > > I've seen them in several project so my guess is that they > > have something to do with using chipscope or that these are the names > > of some sort of global clock net. > > > Thanks in advance, > > Peter > > using chipscope, you should see an edif-netlist like "icon.edn" or > something > like this, that will integrated automatically within your toplevel > design running ngdbuild. > I guess, you'll find a file called "icon.ncf" within the same > directory > > If you have a look at it's content with a simple editor, you should > find said timing-constraints - and they will be automatically linked > to your design, too. > > They are needed to guarantee chipscope's functionality (JTAG- > clock,...) > > hope, it helps, > JochenArticle: 126089
<cs_posting@hotmail.com> wrote in message news:1195063469.146499.122220@v3g2000hsg.googlegroups.com... > > Otherwise you're just trying to represent in messy pictures what is > much clearer in text. > Dear Whoeveryouare, That statement may well be true in your case. However, I know of engineers who say exactly the reverse! Don't get me wrong, IMHO, large projects with experienced engineers are best served by using a HDL. That said, there are circumstances where I believe schematics have an advantage. You already mentioned one of these cases, when you wrote about a block diagram. Another case is when an engineer is first starting to use FPGAs. This is the situation being discussed in this thread. The use of schematics allows some rookie engineers to get a better grasp of how their circuits are realised in the FPGA. The schematic can clearly show individual FFs and gates. I'd suggest this is particularly true when engineeers are coming from a software background. The schematic design flow is so different from software development, it forces a different 'hardware' mindset. When these same engineers 'progress' to RTL, the experience they've gained from the circuit structures they've built with schematics is very useful. YMMV. Cheers, Syms.Article: 126090
"austin" <austin@xilinx.com> wrote in message news:fhf61e$o351@cnn.xilinx.com... > Amal, > > An unencrypted bit file is 3 to 7% 1's (97 to 93% 0's) typically. > > An encrypted bit file is roughly 50% 1's and 0's. > > Real easy to tell them apart. > > Austin Hi Austin, What if the FPGA design had all the BRAMs initialised to 1's? ;-) Cheers, Syms.Article: 126091
Herbert Kleebauer wrote: > A few month ago I asked for a recommendation for FPGA (not a ready to use demo board) > which could be handled with simple home equipment. I got the link to: > > http://www.enterpoint.co.uk/moelbryn/darnaw1.html > > We ordered a few samples and did some experimenting. Here the documentation > for a simple 16 bit CPU implemented on the DARNAW1. It includes also a step by > step introduction which should allow anybody still unfamiliar with FPGA design > to implement the demo in less than a hour. > > ftp://137.193.64.130/pub/mproz/mproz3_e.pdf (documentation) > ftp://137.193.64.130/pub/mproz/mproz3.zip (documentation + schematics) > > Conclusion: > The board is great, not just an other demo board, but rather a package > converter from the FPG ball grid to a pin grid array with the necessary > voltage converters and program flash on board. Sadly the same can't be > said about the current Xilinx software (schematic editor + simulator), > so we will try to stay as long as possible with the X3000 chips and the > old Xilinx DOS software (with ViewLogic schematic entry + simulator). So, hundreds of man months of SW effort have seen a nett-step backwards ? Can you elaborate on some of the drawbacks, and perhaps Xilinx can fix them ? -jgArticle: 126092
Herbert Kleebauer wrote:
> The board is great, not just an other demo board, but rather a package
> converter from the FPG ball grid to a pin grid array with the necessary
> voltage converters and program flash on board. Sadly the same can't be
> said about the current Xilinx software (schematic editor + simulator),
> so we will try to stay as long as possible with the X3000 chips and the
> old Xilinx DOS software (with ViewLogic schematic entry + simulator).
Maybe John will do an altera board someday.
The quartus schematic capture is clean and solid.
The free simulator is also limited to waves,
but the licensed version has a very usable version of modelsim
and an rtl viewer that covers verilog and vhdl.
-- Mike Treseler
Article: 126093Symon, Even with all BRAM's to 1's, the files will still look really very different in terms of one's density! One of the side-effects on a good encryption method is that it makes the data look like "noise." So, what they need is a way to tell the difference between "noise" and a unencrypted bit file. You could play it through a sound card, and you could immediately tell the difference, for example. (I can see the assembly line taking 'dance to the bit stream breaks') Or, you could display the bit file on a monitor with 24 bit color, in .bmp format (or .tiff, or whatever) and the encrypted files will look like grey splotches of many colored pixels, and the unencrypted bit files will look like structures of some sorts (not "noise" at all!). By the way, I use this last method to evaluate true random number generators, as your brain can view a big (1760 X 1024 X 24 bit) picture and almost instantly "see" non-random behavior ... must have something to do with us all coming from hunters on the veld two million years ago ... If you display them fast enough, you can even make a "movie" or if you play them fast enough, a symphony. AustinArticle: 126094
Hello, I have generated a block-ram based FIFO queue (2 independent clocks, 2 inputs, 1 output) with the use of Core Generator. In the creator I used the 36 bit data bus. Is it possible to parameterize this variable? I think, that the Xilinx doesn't give such possibility. The generated code: LIBRARY ieee; USE ieee.std_logic_1164.ALL; -- synthesis translate_off Library XilinxCoreLib; -- synthesis translate_on ENTITY fifa IS port ( din: IN std_logic_VECTOR(35 downto 0); rd_clk: IN std_logic; rd_en: IN std_logic; rst: IN std_logic; wr_clk: IN std_logic; wr_en: IN std_logic; dout: OUT std_logic_VECTOR(35 downto 0); empty: OUT std_logic; full: OUT std_logic); END fifa; ARCHITECTURE fifa_a OF fifa IS -- synthesis translate_off component wrapped_fifa port ( din: IN std_logic_VECTOR(35 downto 0); rd_clk: IN std_logic; rd_en: IN std_logic; rst: IN std_logic; wr_clk: IN std_logic; wr_en: IN std_logic; dout: OUT std_logic_VECTOR(35 downto 0); empty: OUT std_logic; full: OUT std_logic); end component; -- Configuration specification for all : wrapped_fifa use entity XilinxCoreLib.fifo_generator_v4_1(behavioral) generic map( c_has_int_clk => 0, c_rd_freq => 1, c_wr_response_latency => 1, c_has_srst => 0, c_has_rd_data_count => 0, c_din_width => 36, c_has_wr_data_count => 0, c_full_flags_rst_val => 1, c_implementation_type => 2, c_family => "virtex2p", c_use_embedded_reg => 0, c_has_wr_rst => 0, c_wr_freq => 1, c_underflow_low => 0, c_has_meminit_file => 0, c_has_overflow => 0, c_preload_latency => 1, c_dout_width => 36, c_rd_depth => 1024, c_default_value => "BlankString", c_mif_file_name => "BlankString", c_has_underflow => 0, c_has_rd_rst => 0, c_has_almost_full => 0, c_has_rst => 1, c_data_count_width => 10, c_has_wr_ack => 0, c_use_ecc => 0, c_wr_ack_low => 0, c_common_clock => 0, c_rd_pntr_width => 10, c_use_fwft_data_count => 0, c_has_almost_empty => 0, c_rd_data_count_width => 10, c_enable_rlocs => 0, c_wr_pntr_width => 10, c_overflow_low => 0, c_prog_empty_type => 0, c_optimization_mode => 0, c_wr_data_count_width => 10, c_preload_regs => 0, c_dout_rst_val => "0", c_has_data_count => 0, c_prog_full_thresh_negate_val => 1020, c_wr_depth => 1024, c_prog_empty_thresh_negate_val => 3, c_prog_empty_thresh_assert_val => 2, c_has_valid => 0, c_init_wr_pntr_val => 0, c_prog_full_thresh_assert_val => 1021, c_use_fifo16_flags => 0, c_has_backup => 0, c_valid_low => 0, c_prim_fifo_type => "1kx36", c_count_type => 0, c_prog_full_type => 0, c_memory_type => 1); -- synthesis translate_on BEGIN -- synthesis translate_off U0 : wrapped_fifa port map ( din => din, rd_clk => rd_clk, rd_en => rd_en, rst => rst, wr_clk => wr_clk, wr_en => wr_en, dout => dout, empty => empty, full => full); -- synthesis translate_on END fifa_a; There are 2 parameters: c_din_width =>36 and c_dout_width => 36. I can't use here values greater than 36. What is the use of this parameters? Can I change this parameters values to i.e. 20? I would like to use the queue with different sizes of the data bus. Is it a good solution to create a maximum size data bus and use it to write there smaller data? Or maybe it is better to create a 1bit queue, and with the use of GENERATE command generate N 1 bit queues to have a N-bit queue? Device is Virtex2Pro. Regards, zlotawyArticle: 126095
cs_posting@hotmail.com wrote: > > Otherwise you're just trying to represent in messy pictures what is > much clearer in text. > I don't entirely agree with you. Good use of hierarchy makes schematic far clearer than text for many if not most circuits. It also facilitates reuse, maintainability etc. The problem is most schematic users don't make very good use of hierarchy at all, and the tools are of little help there as well. Back when I used Viewlogic, I had constructed a rather extensive library of 1 and 2 bit slices, of components built up from those slices and of macro functions. I had honed that system well enough so that the top level designs looked like signal processing block diagrams, and as you worked down through the hierarchy you got to progressively simpler elements. That methodology also allowed me to put placement constraints in the design. The real advantages to using an HDL are: 1) they are readable with just a text editor, and therefore can be archived without also archiving the tool and the computer. This also means version control is easier. 2) It is far easier to build parameterized objects with an HDL. This provides a means for faster reuse. This is mainly a tools issue, since nothing was really made to automate parameterized schematics. 3) Currently, the tools for HDL designs are far superior to the schematic tools, mainly because that is where the effort has been focused over the last decade.Article: 126096
One of these days we might have an Altera based product. We have been asked by various people to do one and my very able team could turn an Altera product very quickly if we decided to do that. The current record by the team for delivering a working main development board to a customer is 18 days from start of development. Most of our competitors couldn't probably get the spec written in that time. That product is still in the range and shipping. It's a kind of funny thing that over the years Enterpoint at various points in time actually did more Altera based work that Xilinx. A long time ago we considered joining Altera's ACAP but Xilinx's equivalent at the time came up as a better deal at the same time and the rest is history. Back to the present and we have an exciting roll out of products coming. We have just about caught up on things we have promised for a while and December and January will start to see the release of things we have not talked about yet in any detail. Some very different concepts to appear as well as the nearly predictable. Our own PCIE core is in beta and working well on our PCIE Broaddown4 and that will drive PCIE based boards that are the predictable end of the set of releases coming. John Adair Enterpoint Ltd. On 14 Nov, 19:01, Mike Treseler <mike_trese...@comcast.net> wrote: > Herbert Kleebauer wrote: > > The board is great, not just an other demo board, but rather a package > > converter from the FPG ball grid to a pin grid array with the necessary > > voltage converters and program flash on board. Sadly the same can't be > > said about the current Xilinx software (schematic editor + simulator), > > so we will try to stay as long as possible with the X3000 chips and the > > old Xilinx DOS software (with ViewLogic schematic entry + simulator). > > Maybe John will do an altera board someday. > The quartus schematic capture is clean and solid. > The free simulator is also limited to waves, > but the licensed version has a very usable version of modelsim > and an rtl viewer that covers verilog and vhdl. > > -- Mike TreselerArticle: 126097
On Nov 14, 1:33 pm, "Symon" <symon_bre...@hotmail.com> wrote: > You already mentioned one of these cases, when you wrote about a block > diagram. Another case is when an engineer is first starting to use FPGAs. > This is the situation being discussed in this thread. The use of schematics > allows some rookie engineers to get a better grasp of how their circuits are > realised in the FPGA. The schematic can clearly show individual FFs and > gates. I'd suggest this is particularly true when engineeers are coming from > a software background. The schematic design flow is so different from > software development, it forces a different 'hardware' mindset. When these > same engineers 'progress' to RTL, the experience they've gained from the > circuit structures they've built with schematics is very useful. I still think this is a mistake on an order comparable to trying to use LabView to wire up assembly language instructions into a useful program. There's a time and a place to learn about real circuit implementations of simple computational structures and of state machines - made of gates and flip flops, and of gates and flip flops made of transistors. But that's not effectively how things work in an FPGA. FPGAs run on logic equations, which are going to be re-interpreted into the proprietary assortment of available doodads by the tools anyway. Nobody should be instantiating discrete gates in an FPGA (iobuffers and other special ones exempted), instead they should be writing equations - HDL code - that accomplish the intended function in a concise and comprehensible way. The problem with schematic entry is that it's instantation-centric. If you are using your schematic at a block diagram level to wire up big modules, that's good. But if you are using it at a detailed level to instantiate gates in a real project (or even HDL to instantiate them), that's just silly. You should be writing equations - but how do you enter equations in a schematic? This is probably one reason why state machine graphical entry exists - it's still arguably a non-serious tool, but at least it's focused on what the circuit is supposed to do, not the obscuring detail of how it does it.Article: 126098
On Nov 14, 2:41 pm, Ray Andraka <r...@andraka.com> wrote: > cs_post...@hotmail.com wrote: > > > Otherwise you're just trying to represent in messy pictures what is > > much clearer in text. > > I don't entirely agree with you. Good use of hierarchy makes schematic > far clearer than text for many if not most circuits. Yes, good use. That's why I suggested a top-level block diagram schematic made of HDL coded modules could be good. And yes, it's extensible down the hierarchy to a degree. But sooner or later you will get down to HDL modules, either your own or the vendor mega function libraries. > The problem is most schematic > users don't make very good use of hierarchy at all Exactly. > The real advantages to using an HDL are: > 1) they are readable with just a text editor, and therefore can be > archived without also archiving the tool and the computer. This also > means version control is easier. That says to me that the graphical block diagrams should be complexity constrained: - they should be legible on a letter sized piece of paper (as well as on your monitor without scrolling) - they shouldn't take more than an hour to re-create from the paper, either in a buggy new graphical tool or in a textual HDL It's when people try to create complexity in the graphical representations - by not using hierarchy - that their unsuitability shows up.Article: 126099
Hi Chris, I added some comments below. <cs_posting@hotmail.com> wrote in message news:1195069602.205639.51830@o3g2000hsb.googlegroups.com... > On Nov 14, 1:33 pm, "Symon" <symon_bre...@hotmail.com> wrote: > >> You already mentioned one of these cases, when you wrote about a block >> diagram. Another case is when an engineer is first starting to use FPGAs. >> This is the situation being discussed in this thread. The use of >> schematics >> allows some rookie engineers to get a better grasp of how their circuits >> are >> realised in the FPGA. The schematic can clearly show individual FFs and >> gates. I'd suggest this is particularly true when engineeers are coming >> from >> a software background. The schematic design flow is so different from >> software development, it forces a different 'hardware' mindset. When >> these >> same engineers 'progress' to RTL, the experience they've gained from the >> circuit structures they've built with schematics is very useful. > > I still think this is a mistake on an order comparable to trying to > use LabView to wire up assembly language instructions into a useful > program. > > There's a time and a place to learn about real circuit implementations > of simple computational structures and of state machines - made of > gates and flip flops, and of gates and flip flops made of > transistors. But that's not effectively how things work in an FPGA. > FPGAs run on logic equations, which are going to be re-interpreted > into the proprietary assortment of available doodads by the tools > anyway. > OK, but the point I'm trying to make is that schematics can be a good tool to learn how the circuit is implemented _in_an_FPGA_. The FPGA implementation is different than, for example, a discrete logic implementation or an ASIC implementation. When a designer knows how the circuit will be implementated he can tailor his design to fit. The correlation between what is drawn in the schematic and what ends up in the FPGA's LUTs is closer than with an equivalent RTL design, helping the beginner see which structures are good, and which are bad. > > Nobody should be instantiating discrete gates in an FPGA (iobuffers > and other special ones exempted), instead they should be writing > equations - HDL code - that accomplish the intended function in a > concise and comprehensible way. > Usually this is true. However, some designs require extracting the fastest possible timing from the FPGA, or the smallest resource usage. A designer can code the design in RTL appropriately and hope the synthesis tool gets the message or they can instantiate FPGA primitives in their RTL. It's my contention that a designer who has a grounding of the underlying structure of the FPGA will be at an advantage, and one way to get that knowledge is to design as a beginner with schematics. > > The problem with schematic entry is that it's instantation-centric. > Which is my point. Sometimes instantiation is useful for the reasons I outlined above. > > If you are using your schematic at a block diagram level to wire up > big modules, that's good. But if you are using it at a detailed level > to instantiate gates in a real project (or even HDL to instantiate > them), that's just silly. You should be writing equations - but how > do you enter equations in a schematic? > Again, a fair point. But the context of this thread is education, not 'real projects', which, I think, changes what is 'good'. > > This is probably one reason why state machine graphical entry exists - > it's still arguably a non-serious tool, but at least it's focused on > what the circuit is supposed to do, not the obscuring detail of how it > does it. > > I've never used state machine graphical entry, I can't comment. Regards, Syms.
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