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
Peter Alfke wrote: > If you have a single-pole double-throw switch with break before make > (or a three-position switch) just connect the center to a pin,and the > two terminals to Vcc and ground. Then, inside the chip make the input > drive the active, non-inverted output on the same pin. That creates a > latch, that you can force either way, and it will respond within about > a nanosecond, and will ignore all bounce. Use the lowest drive > strength setting. I was about to comment on the current surge before it switches, but I suppose at low drive setting it should be fine. I might wonder, though, on outputs with only high drive current. -- glenArticle: 134176
Hi everybody, I want to ask if the HWICAP is supported and tested in Virtex-5 Boards (ML501 and ML505). I used HWICAP in Virtex -II pro and it was working in a good way to configure certain LUTs., and i want to use Vertix-5 instead of Virtex- II pro to gain the new feature GLUTMASK (with this feature i don't have to care about the LUTs distribution ). does anyone know about this. fatmaArticle: 134177
On Jul 9, 11:00 am, lixia....@gmail.com wrote: > On 6=D4=C21=C8=D5, =CF=C2=CE=E77=CA=B159=B7=D6, Atukem <atu...@googlemail= .com> wrote: > > > > > On May 27, 1:55 pm, fmostafa <fatma.abouele...@ugent.be> wrote: > > > > hi all, > > > > I am trying to useHWICAPto configure certain LUTs , I guess that > > > starting with the examples from XILINX will be a good start, the > > > problem that after many trials and of course nothing working, I > > > noticed that the DONE bit which in the status reg in theHWICAPis > > > low all the time so nothing is working, but before calling the > > > function XHwIcap_Initialize the Done bit is high , I don't know if > > > what I noticed is really a problem as I guess or not, I am using EDK > > > 9.1 and XUP board for XC2VP30 under Linux, I don't may be the problem > > > in Linux or some thing else. > > > > thanks > > > > fatma > > > Could you give a little bit more detail about you system, when it > > stops working, does it actually complete the initialisation process, I > > guess you might be using microblaze .... > > hi fatma, > i have the same problem with Atukem,and it hanppens when call > XHwicap_DeviceRead function,the return value is "Device is busy".So,in > fact,the initialisation process is not complete successfully. > the value of M0M1M2 should be set only through the switches on the > board or both in the gitgen.ut file? Is there anything else shoule be > noticed except the value of M0M1M2 and persist? hi Atukem; my problem is solved when i choose v1_00_b for the ip and v1_00_a for the driver. i hope this can solve your problem fatmaArticle: 134178
glen herrmannsfeldt wrote: > Peter Alfke wrote: > >> If you have a single-pole double-throw switch with break before make >> (or a three-position switch) just connect the center to a pin,and the >> two terminals to Vcc and ground. Then, inside the chip make the input >> drive the active, non-inverted output on the same pin. That creates a >> latch, that you can force either way, and it will respond within about >> a nanosecond, and will ignore all bounce. Use the lowest drive >> strength setting. > > > I was about to comment on the current surge before it switches, > but I suppose at low drive setting it should be fine. I might > wonder, though, on outputs with only high drive current. That's not a bug, it's a feature!: It does Contact cleaning!! ;) -jgArticle: 134179
rickman wrote: > On Jul 27, 3:51 pm, Jim Granville <no.s...@designtools.maps.co.nz> > wrote: > >>rickman wrote: >> >>>I think whether this code works for you depends on the push button. I >>>have some tactile switches that initially showed *no* bouncing. After >>>just a week or two of use they bounce so badly that it is impossible >>>to debounce them. >> >>>The best switch to debounce is a double throw switch. The FF stays in >>>a given state until the other contact is made. Very simple, but it >>>requires two inputs and a more complex switch. >> >>Yes, a SPCO switch (classic Micro-switch action) is more complex, >>as it has an extra contact, but I cannot see >>the 'requires two inputs' in any I have used ? >> >>Wire one end to Vcc, one to GND, and the contact to the Pin, >>and enable the Pin-Keep if you like, and you are done. >> >>Did you mean a SET/RESET action, which needs two pins, and two >>resistors (can be pin-pulldowns) ? >> >>SPCO switches should be the default on demo-boards, as you can >>also clock off them... > > > If you don't have the "pin-keep" (bus-hold) enabled (or available) > what state is the input in while the switch is in transition? I would > think the input would be floating which is not a good idea. In > essence, you are asking the capacitance of the input to perform the > bus-hold function. > > To be honest, I had to look up a SPCO switch. It seems to be a three > position switch. Why do you need three positions? Wouldn't a SPDT > with break before make do what you are describing? Yes, SPCO and SPDT are effectively interchangable (change Over/Double Throw) - The venerable Microswitch has that, as does the Digitast buttons. Digikey shows those for 28c+cap -jgArticle: 134180
Hi comp.arch.fpga, I am doing a little research on die sizes, mainly because I want to argue how much you have to trade hardware flexibility against die size. The second point is, I'm just curious if FPGAs are still the biggest high-volume ICs on the market or if they are already beaten by NVIDIAs newest GT280 GPU (which has about 576 square mm at 65nm). I haven't found anything useful on the web yet, that's why I am asking here. What are the approximate die sizes of the state-of-the-art high density FPGAs? (For exampe Virtex5 XC5VLX220, LX330 or SX240T, and the Stratix IV EP4SGX360, SGX530, SE530 or SE680? Thanks in advance! Best regards, SimonArticle: 134181
"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message news:488f0139$1@clear.net.nz... > > Yes, SPCO and SPDT are effectively interchangable > (change Over/Double Throw) - The venerable Microswitch has that, > as does the Digitast buttons. Digikey shows those for 28c+cap Hmm SPDT switches come in two varieties. Break before make and make before break. There is a danger you'll get one where the switch will momentarily connect all 3 terminals together for a short period of time. It's important to check and specify you get the right one for this application.Article: 134182
On Mon, 28 Jul 2008, Rickman wrote: |-------------------------------------------------------------------------| |"[..] | | | |A language does not need to protect you from yourself if you are any | |good. I realized a long time ago that computer tools were initially | |designed for computer designers. But there aren't enough good | |designers to go around. So the tools were dumbed down so that the | |masses could use them. I don't agree that this is even needed." | |-------------------------------------------------------------------------| I once read a claim in a book (unfortunately I can not rememember which one and it shall be many months before I shall be able to check), that Albert Einstein was once returning home via the visitors' entrance of the complex in which he resided at in those days, and he asked for Mr. or Dr. Einstein, and a few seconds later he admitted to being embarrassed because after asking for Einstein, he remembered that he was Einstein. People do not perform at their best at every moment they are working. If I cycle a bike near broken glass on the road, then I tend to cycle more cautiously than when the road is clear. I almost never cycle without a helmet though I have never been in a situation in which I would have been seriously injured or died if I had not been wearing a helmet. People who are not mountain climbers had been surprised to hear that I have climbed without a rope. I do not usually climb high enough to die from a fall on my own without a rope, but I have done it (without a helmet). When doing so, I have paid a lot of attention to not making a fatal mistake. (Much better climbers than I had died, so being excellent at something does not guarantee that something unfortunate shall never happen.) Even so, I tend to ordinarily deliberately go towards a handrail when I am about to walk on a very wide staircase. Electric sockets and plugs in every country in which I have resided have been designed in such a way that they can not be easily connected in a dangerous fashion. |-------------------------------------------------------------------------| |" What | |is needed is a bit of education in how to write code that is not hard | |to debug and then getting people to use those principles as well as | |the principles of good test techniques. | | | |[..]" | |-------------------------------------------------------------------------| A little education does not go a long way. C. P. G.Article: 134183
On Mon, 28 Jul 2008, Diogratia wrote: |-----------------------------------------------------------------------| |"[..] | | | |The BNF for VHDL 93 for instance, isn't semantically complete, nor is | |it non-ambiguous. You actually have to understand the language to | |contemplate making changes to it, and the BNF isn't sufficient." | |-----------------------------------------------------------------------| True (as with any language which is not trivial) and you still need to actually understand the language in order to accomplish... |-----------------------------------------------------------------------| |" It | |seems a bit overkill to start anew then replicate most of VHDL. | | | |A preprocessor sufficient for Mr. Rickman's preferred concurrent | |assignment statement form could easily be written in a small AWK or | |Perl script, passing through elements of a source file not affected. | |[..] | | | |You could also conceivably translate to your preferred syntax from | |VHDL in an editor like emacs or joe, write in your preferred syntax | |abstraction and store the file in VHDL. [..]" | |-----------------------------------------------------------------------| ...any of these perfectly. A first-order approximation would be much easier in one of those than modifying the BNF, but a proper integration instead of a first-order approximation would not be any easier. |-----------------------------------------------------------------------| |"[..] a preprocessor [..] | |[..] a method shared with the first C++ | |implementation." | |-----------------------------------------------------------------------| Indeed, and the programmer of the first C++ implementation devoted a chapter in his book "The Design and Evolution of C++" against using the C preprocessor. Furthermore, Brian W. Kernighan (co-inventor of AWK) co-authored the book "The Practice of Programming" in which such lexical substitution (changing the syntax underfoot, as it was described) was also discouraged.Article: 134184
Fatma, Yes, the ICAP primitives are tested by the test program at the factory. And yes, ICAP is supported in Virtex 5. AustinArticle: 134185
Simon, The typical FPGA that touts itself as the "biggest" has traditionally been reticle-limited, that is, the die size is the largest that is able to be accommodated by the photo-lithography systems. Those dimensions are about 25mm by 28mm (roughly, plus or minus a few mm, given the need for test structures, scribe lines, etc.). So, at one time, the xc3090 die was the 'monster' of its day at around one square inch. And 20 years later, the xc5vlx330t is roughly 1000 times more logic/bits in a similar area. Almost a perfect fit to Moore's Law. AustinArticle: 134186
On Mon, 28 Jul 2008 21:31:43 +0000, Nico Coesel wrote: > I see your point and I agree. I would like to write my programmable > logic in C as well. Neither VHDL or Verilog are easy to use. For starters, standard C doesn't support threading + concatenation + arbitrary vectors sizes, but you could add those. I checked out http://en.wikipedia.org/wiki/C_to_HDL and whilst browsing there it seems some have added these sorts of features to a subset of C, but then it isn't C anymore, and so you haven't really gained much, if anything as far as I can see. Of course there's systemC. Although I don't see that has any advantages over VHDL if you look at the examples here: http://www.asic-world.com/examples/systemc/seq.html Regards Paul.Article: 134187
On Jul 29, 5:54=A0am, "Simon Heinzle" <shein...@inf.ethz.ch> wrote: > Hi comp.arch.fpga, > > I am doing a little research on die sizes, mainly because I want to argue > how much you have to trade hardware flexibility against die size. The sec= ond > point is, I'm just curious if FPGAs are still the biggest high-volume ICs= on > the market or if they are already beaten by NVIDIAs newest GT280 GPU (whi= ch > has about 576 square mm at 65nm). > > I haven't found anything useful on the web yet, that's why I am asking he= re. > What are the approximate die sizes of the state-of-the-art high density > FPGAs? (For exampe Virtex5 XC5VLX220, LX330 or SX240T, and the Stratix IV > EP4SGX360, SGX530, SE530 or SE680? > > Thanks in advance! > > Best regards, > Simon There are many aspects: Technology (Moore's Law) reduces the min feature size by the square root of 2 every 2 years, now perhaps every 3 years, thus doubling the transistor count per area each time. Architecture tries to make best use of the additional transistors Chip Circuit Design and lay-out comes up with the most efficient implementation Manufacturing is constrained by the reticle size, and by the "defect density", to achieve reasonable yield and thus acceptable cost at the high end. As a result, the very largest FPGAs are around 25 mm square, or 600+ square millimeters. That has not changed for many years. There is always a strong user demand for the largest possible FPGAs. I think it's from all those users who really wanted something even bigger, even at a higher price. We have observed that "high demand at the high end" ever since the X3090 in 1988. Its logic resources were almost exactly 1000 times less than those of the newest top-end Virtex-5 devices. Moore's Law in action ! And the density increase will continue... Peter AlfkeArticle: 134188
On Jul 29, 12:08=A0pm, Paul Taylor <pt@false_email.co.uk> wrote: > On Mon, 28 Jul 2008 21:31:43 +0000, Nico Coesel wrote: > > I see your point and I agree. I would like to write my programmable > > logic in C as well. Neither VHDL or Verilog are easy to use. > > For starters, standard C doesn't support threading + concatenation > + arbitrary vectors sizes, but you could add those. > > I checked outhttp://en.wikipedia.org/wiki/C_to_HDLand whilst browsing > there it seems some have added these sorts of features to a subset of C, > but then it isn't C anymore, and so you haven't really gained > much, if anything as far as I can see. > > Of course there's systemC. Although I don't see that has any advantages > over VHDL if you look at the examples here: > > http://www.asic-world.com/examples/systemc/seq.html > > Regards > > Paul. Each language has its merits and uses. SystemC is great for modeling system-level, transaction-level and HW/SW interactions. Although I love operator overloading when it makes sense, creating new operators would just create a whole new language and make it confusing. I would rather stick with operator overloading only for cases that makes new constructs easier to use and understand. Operator overloading is great with object-oriented languages like SystemVerilog. Until vendors add operator overloading to SystemVerilog, and OOP additions to VHDL are approved, I think you just need to stick with what you have. -- AmalArticle: 134189
Fred wrote: > "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message > news:488f0139$1@clear.net.nz... > >>Yes, SPCO and SPDT are effectively interchangable >>(change Over/Double Throw) - The venerable Microswitch has that, >>as does the Digitast buttons. Digikey shows those for 28c+cap > > > Hmm SPDT switches come in two varieties. Break before make and make before > break. There is a danger you'll get one where the switch will momentarily > connect all 3 terminals together for a short period of time. It's important > to check and specify you get the right one for this application. I have yet to see a Microswitch that is MBB. Got any references of one that is ? The mechanical design of uSW and closely related Digitast buttons rather excludes that. -jgArticle: 134190
"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message news:488ff776@clear.net.nz... > Fred wrote: >> "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message >> news:488f0139$1@clear.net.nz... >> >>>Yes, SPCO and SPDT are effectively interchangable >>>(change Over/Double Throw) - The venerable Microswitch has that, >>>as does the Digitast buttons. Digikey shows those for 28c+cap >> >> >> Hmm SPDT switches come in two varieties. Break before make and make >> before break. There is a danger you'll get one where the switch will >> momentarily connect all 3 terminals together for a short period of time. >> It's important to check and specify you get the right one for this >> application. > > I have yet to see a Microswitch that is MBB. Got any references of > one that is ? > The mechanical design of uSW and closely related Digitast buttons rather > excludes that. > I agree that many forms of switches are break before make. The thing is I have come across make before break and they have ended up causing grief. It's just something I would bear in mind.Article: 134191
Thanks a lot for your replies! Cheers, SimonArticle: 134192
Does anyone know of a way to modify which VHDL libraries ISE automatically uses in VHDL files created by the new file wizard? It seems to always use std_logic_arith and std_logic_unsigned, and I can't find a setting anywhere to modify this. I remember from my days of using Quartus that there was a text are in the settings menus where this could be changed. There's got to be something similar in ISE, right? DaveArticle: 134193
Let me post this again without all the reply message junk... G=F6ran, I feel as though I'm very close to implementing this, but still have some questions (hopefully my last few questions!) - I'll first document the steps I have taken: - I implemented my module as a pcore by using the 'Create and Import Peripheral' wizard - this generated the HDL wrapper file as an FSL bus interface (is that correct?). I deleted this file and simply imported my two VHDL LCD files (LCD.vhd, LCD_top.vhd - LCD.vhd is an internal component of LCD_top.vhd) into this directory. - I then edited the MPD file to look as shown below. As you can see, I commented out the bus interface specifications since there should be no FSL bus connection and edited the port declarations. I also added, but commented an IO_INTERFACE. BEGIN lcd_core ## Peripheral Options OPTION IPTYPE =3D PERIPHERAL OPTION IMP_NETLIST =3D TRUE OPTION HDL =3D VHDL ## Bus Interfaces ##BUS_INTERFACE BUS=3DSFSL, BUS_STD=3DFSL, BUS_TYPE=3DSLAVE ##BUS_INTERFACE BUS=3DMFSL, BUS_STD=3DFSL, BUS_TYPE=3DMASTER #IO_INTERFACE IO_IF =3D lcd_0 ## Peripheral ports PORT clk =3D "", DIR=3DI, SIGIS=3DClk PORT reset =3D "", DIR=3DI, SIGIS=3DRst PORT din_ready =3D "", DIR=3DI PORT din =3D "", DIR=3DI, VEC=3D[0:7] PORT busy =3D "", DIR=3DO PORT LCD_D =3D "", DIR=3DO, VEC=3D[8:11] PORT LCD_E =3D "", DIR=3DO PORT LCD_RS =3D "", DIR=3DO PORT LCD_RW =3D "", DIR=3DO END - I edited the PAO file to include my two VHDL LCD modules (LCD.vhd and LCD_top.vhd), and removed the wrapper file that was originally there by default when created. - In the 'Project Information Area', I added the user IP module from the 'IP Catalog' tab - In 'System Assembly View', and the 'Ports' tab, I expanded the core and made the four LCD_x outputs external ports. Now I'm assuming this is where you must connect the remaining signals to the FSL interface, but I don't know how. I choose the option 'New Connection', but this simply edits the MHS file port name. I manually made changes as shown below, but to no avail. BEGIN lcd_core PARAMETER INSTANCE =3D lcd_core_0 PARAMETER HW_VER =3D 1.00.a PORT LCD_RW =3D lcd_core_0_LCD_RW PORT LCD_RS =3D lcd_core_0_LCD_RS PORT LCD_E =3D lcd_core_0_LCD_E PORT LCD_D =3D lcd_core_0_LCD_D PORT clk =3D sys_clk_s PORT reset =3D sys_rst_s # PORT din_ready =3D lcd_core_0_din_ready # PORT din =3D lcd_core_0_din # PORT busy =3D lcd_core_0_busy PORT din_ready =3D FSL0_M_Write PORT din =3D FSL0_M_Data (24 to 31) PORT busy =3D FSL0_M_Full END - Lastly, I added the external ports from the LCD module to the UCF file. First, does this seem like the correct process to implement the hardware peripheral? In the MPD file, do I need to uncomment the IO_INTERFACE option for the LCD_x external outputs? How do I make the connections to the FSL interface within Platform Studio? When I try to generate the bitstream, I get the following error - I'm sure I'm missing some type of port declaration, or am not performing the right set of steps: ERROR:MDT - INST:lcd_core_0 PORT:din_ready - C:\EDK_Test_LCD \system.mhs line 187 - port is driven by a sourceless connector Anyway, thanks so much for helping me throughout this process, and I look forward to hearing back from you again! RayArticle: 134194
Guys, Using ISE10.1 my design's timing fails, whereas it used to be fine. Here's the problem:- In ISE8.2 the P&R tools had the sense to use the topcyf path to get onto the carry chain which takes 1.162ns file:///C:/Xilinx/10.1/ISE/doc/usenglish/help/delay_types/html/web_ds_sp3/ta_topcyf.htm In ISE10.1 the P&R tools seem intent on using the tbxcy path to get onto the carry chain which, although it saves a LUT, takes 1.882ns adding 720ps delay. file:///C:/Xilinx/10.1/ISE/doc/usenglish/help/delay_types/html/web_ds_sp3/ta_tbxcy.htm I tried messing about with the ISE10.1 Map and P&R properties, with no luck. In MAP, I changed 'Optimization strategy' to speed. I set the tick box for 'Perform timing-driven packing and placement'. Any clues? Thanks, Symon.Article: 134195
On Jul 28, 12:22 pm, Rob Gaddi <rga...@technologyhighland.com> wrote: > rickman wrote: > > On Jul 26, 9:38 am, Mike Treseler <mtrese...@gmail.com> wrote: > >> rickman wrote: > >>> BERTEn <= BERTSel and GenEn ? not SyncPOSSel : not GenPOSSel; > >> if BERTSel and GenEn then > >> BERTEn <= not SyncPOSSel; > >> else > >> BERTEn <= not GenPOSSel; > >> end if; > > > One of us doesn't understand the precedence (I'm not sure which > > one...). That is always a good reason for not allowing precedence > > defaults to define an expression... > > > BERTEn <= BERTSel and (GenEn ? not SyncPOSSel : not GenPOSSel); > > > Is that more clear? > > > Rick > > As a potential three-line solution: > > signal BERTEn_mux_n : std_logic; > ... > BERTEn_mux_n <= SyncPOSSel when (GenEn = '1') else GenPOSSel; > BERTEn <= BERTSel and (not BERTEn_mux_n); > > And trust in your synthesis tools to fold the intermediate signal. It > certainly eliminates any ambiguity about what's going on where in what > order. Why that as opposed to BERTEn <= BERTSel and (GenEn ? not SyncPOSSel : not GenPOSSel); ??? Is this not unambiguous and readable? I guess you are pointing out solutions that are available. Ok, thanks.Article: 134196
On Jul 28, 12:12 pm, Andy <jonesa...@comcast.net> wrote: > On Jul 28, 9:41 am, rickman <gnu...@gmail.com> wrote: > > > A language does not need to protect you from yourself if you are any > > good. I realized a long time ago that computer tools were initially > > designed for computer designers. But there aren't enough good > > designers to go around. So the tools were dumbed down so that the > > masses could use them. I don't agree that this is even needed. What > > is needed is a bit of education in how to write code that is not hard > > to debug and then getting people to use those principles as well as > > the principles of good test techniques. > > > Rick > > If you're so in love with Verilog's capabilities, use verilog. > > The rest of us, who are apparently not any good since we prefer a > strong language like VHDL, will continue to use VHDL. > > BTW, just in case you want to risk taking our inferior advice, if you > are dead set on a more concise notation in currently legal vhdl, then > create an array type indexed by boolean (or std_logic). Then create a > signal/variable and assign the two elements appropriately. Now you can > implement your concise expression by indexing the array with your > selection expression. Ya know, I'm just having a conversation here. If you don't like the topic or don't care for my opinions, why do you bother to participate? The "attitude" you are showing is not appropriate. RickArticle: 134197
On Jul 28, 9:04 pm, Brian Drummond <brian_drumm...@btconnect.com> wrote: > > Yes; the selection would have been an expression; unfortunately it would > have been a nasty wart in the syntax and probably broken the parsing > model. For very limited benefit; 2 is a special case of n. I'm not sure why it would break the parsing model. If it were a built- in operator, I would think it would be simple to handle, but then I am not a parser writer (although this would be easy to code in Forth, the selection operator is nearly an exact match to IF ELSE THEN). > The conditional assignment is a second best for usability, but fits the > big picture better. Assignment can take other characteristics; "after > 4ns" or "guarded", so one more doesn't upset the cart, and it is not > limited to 2 inputs. If selection is an operator it still fits the assignment model. I don't think you would lose anything by having this available. It doesn't preclude using the conditional assignment and you can add the same types of modifiers to a simple assignment. > I think where we differ is that I side with keeping the big picture > simple and consistent; I believe it pays in the long run, despite the > short term cost, such as an occasional extra line (not 9 please!). > Unfortunately that makes VHDL a hard sell, because it doesn't come > across clearly in a little 1-month or 3-month project. I am a firm believer in the big picture and the long term pay off. I just see a lot of things in VHDL that I think do not make a significant contribution to either of these things and can be improved. There are others who see the same things and there are many proposed improvements to VHDL. Just look at how string constants were originally used and how they have been improved over the years. There is another improvement coming having to do with based constants ,IIRC. RickArticle: 134198
rickman wrote: > Ya know, I'm just having a conversation here. If you don't like the > topic or don't care for my opinions, why do you bother to > participate? The "attitude" you are showing is not appropriate. Attitude is what keeps things interesting. Everybody's got one. -- Mike TreselerArticle: 134199
On Jul 28, 5:31 pm, n...@puntnl.niks (Nico Coesel) wrote: > rickman <gnu...@gmail.com> wrote: > > >The problem is not so much reading the code, but is writing. I think > >in the terms of the logic, usually a schematic/block diagram. Then I > >try to express that logic in the language. It is not uncommon that it > >is simply impossible to express the logic in the form I have drawn > >it. Then I have to convolute it to come up with something that is > >what I have drawn, or at least I hope so. > > I don't think drawing logic is a good way to start. Using flow charts > usually leads to more simple solutions because it is easier for a > human to optimize a flow chart than a bunch of logic symbols. So are you suggesting that my entire approach to logic design is inappropriate? In other words, I am doing it *all* wrong? We all work differently. I would hope that you could understand that. To be honest, I'm not even sure how I would use a flow chart to design data flow. I can draw a block diagram to show the data flow and the control points as well as noting the logic involved in the control points. If the logic is involved and requires state analysis, then I would use a flow chart or design the state machine. But how would a flow chart be used to design the data path? > >Example: A data mux controlled by the output of an AND of a signal and > >the output of a mux. This is four control signals gated together to > >drive the control on the data mux. Here is what I ended up with. > > > BERTEn <= '0' when BERTSel = '0' else > > not SyncPOSSel when GenEn = '0' else > > not GenPOSSel; > > >I don't think that the diagram I drew comes to mind when you see this > >code. Maybe a process with an IF statement would be slightly more > >clear, but the verbosity presents an obfuscation of its own from the > >"clutter" created. > > >process ( BERTSel, SyncPOSSel, GenEn, GenPOSSel) begin > > if (BERTSel = '0') then > > BERTEn <= '0'; > > elsif (GenEn = '0') then > > BERTEn <= not SyncPOSSel > > else > > BERTEn <= not GenPOSSel; > > end if; > >end process; > > >The clutter is from the sheer size of the code. The first three line > >example is a bit obtuse, the 9 line example is large enough to make it > >hard to see the rest of the code and so to see how it fits into the > >big picture. Compare the two examples to this code... > > > BERTEn <= BERTSel and GenEn ? not SyncPOSSel : not GenPOSSel; > > This construction wouldn't be very clear for people that are > relatively new to a programming language. I'd try to avoid it. > > How about: > > process ( BERTSel, SyncPOSSel, GenEn, GenPOSSel) begin > if (BETRSel and Genen)='0' then > BERTEn <= not SyncPOSSel > else > BERTEn <= not GenPOSSel; > end if; > end process; > > The code above makes perfectly clear what you are doing. Besides, I > doubt your examples are describing the same logic. No, your code above is not what I intended. But then I think I covered that before with someone else. I should have used parenthesis to show precedence, which I typically do. But given the context with the other examples, instead of suggesting that my examples didn't match, I think you could have understood the precedence that would have made them match. > >This is what I expect a concurrent statement to look like, not to > >mention that it represents exactly the image I had in my head and on > >the whiteboard, making it much easier to write. > > >I am sure there are those who disagree and much prefer the verbose > >process. Maybe I'm just not cut out for the regimen of VHDL. > > I see your point and I agree. I would like to write my programmable > logic in C as well. Neither VHDL or Verilog are easy to use. > > Yet, you could run your VHDL code through a C pre-processor. This > would allow macro substitution. I don't really want to write in C. I would just like to see VHDL de- verbosed in some cases. Rick
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