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
On Jan 20, 7:17=A0am, Alex <vict...@gmail.com> wrote: > Hello All, > > I am a beginner and want to get an idea how to construct actual FPGA- > based design (a PCB) after this was developed and tested using > development board (I use Xilinx Microblaze 1600E development board). > > My understanding is that as my particular project uses just some of > the features available on the development board (in my design these > are RS232 port, FPGA chip, ADC, DAC, BNC connector for radiofrequency > signal output) only these have to be constructed on my PCB - is this > correct. > I also will need to accomodate on my PCB a ROM where hardware > configuration (which will be downloaded to FPGA chip each time when it > is powered on) is saved. And I do not understand one thing here - this > ROM obviously has to be programmed in advance in order to keep > hardware configuration - is this programming normally done on a > development board? > > Thank you. Please feel free to comment on my questions and tell more > (whatever you find relevant) about construction of FPGA-based designs > for beginners - I am a beginner and interested to learn about any > aspect of this. There is a great deal of superb information in the FPGA manufacturer's data sheets and application notes. You need to pay close attention to power, ground, and decoupling but your attachment to peripherals isn't dependent on how the demo board was laid out as much as where you want things connected. There are pins that are I/O, some pins might be input only, some are designed to be used for clocking, and other special purpose pins might be available. Know the part before you design a board. The memories are typically programmable in-system. If you read the application notes further into the programming and memories, you'll find that a programming adapter hooked up to the PC such as an Altera Byteblaster or a Xilinx USB Platform Cable programmer will get you the attachment you need to program the device when it's already soldered on the board. If your demo board has the programming hardware built in such that you don't have a stand-alone programmer AND the demo board has sockets for at least one type of program memory, then yes: you can program the memory in the demo board and transfer it to your new board. Most designs I've been around have either on-board programmer hookups for the stand-alone programming cables I mentioned or are programmed by a processor that brings up the FPGA as part of the system boot.Article: 145026
On Jan 18, 2:50=A0am, Charles Gardiner <inva...@invalid.invalid> wrote: > > Thanks everyone for your input. My question is relating to the cost of > > a simulator that supports SystemVerilog Verfication, just how much > > should I expect to spend for one license? If its too expensive I'll > > have to stick with sytem testbenches. > > > joe > > To put a ball park on it, about the price of a relatively well-equiped > medium range car ;). If you get a great deal from Aldec / Cadence / > Mentor / Synopsys, maybe the price of a well equiped small car. Why is it so expensive?Article: 145027
On Jan 19, 1:14=A0pm, moogyd <moo...@yahoo.co.uk> wrote: > Hello, > > I am seeing a problem using ISE. I have a verilog top level with pins > including N0, N1, N2, N3, N4 (similar for PX, SX and MX) > > I add a LOC constraint in the UCF file for all pins. For some reason, > the tool seems to be confused by N1, N2, N3 and N4 (but not N0, or any > of PX, SX, MX) > > WARNING:NgdBuild:483 - Attribute "LOC" on "N1" is on the wrong type of > object. > =A0 =A0Please see the Constraints Guide for more information on this > attribute. > > When I report the pinout at the end of the P&R, pins N1..N4 have > disappeared, and I have some new pins (N31, N18, N21, N18) > > My *guess* is that Xilinx uses Nx (x>0) for internal netnames, and it > is getting confused. > > Can anyone confirm and suggest a workaround? (I don't want to change > the pin names) > > Thanks, > > Steven The obvious workaround is to change your pin names... I'm pretty sure you don't need to change them much. Something like N_1, N_2. . . or you could turn them into a bus inout [4:0] N, . . . Then in the .ucf you'd have N<0>, N<1>, etc. Or you can try ISE 10.1 and see if the "problem" has been "fixed." Regards, GaborArticle: 145028
On Jan 19, 3:48=A0pm, "Roger" <rogerwil...@hotmail.com> wrote: > "colin" <colin_toog...@yahoo.com> wrote in message > > news:ab339519-5373-4065-9afb-c8ccfd14f011@p8g2000yqb.googlegroups.com... > > > > > On 19 Jan, 11:29, "Roger" <rogerwil...@hotmail.com> wrote: > >> Due to a bug in the Easy PC software tool from Numberone Systems, I've > >> just > >> had a very time consuming and costly incident. Despite their faulty > >> software > >> costing me a lot of money, the company have so far taken the "hard luc= k" > >> approach. > > >> Has anyone else had any experience of Easy PC? > > >> TIA, > > >> Rog. > > > Roger > > > Our CAD department uses Mentor. We probably pay 50 times per seat the > > cost of Easy PC. We ship the netlist with the gerbers and the PCB > > manufacturers recently reported on one of my designs that the netlist > > automatically generated from the gerbers showed power shorted directly > > to ground. > > Software is provided "as is", if you need to rely on its output you > > need to be able to check it via such a third party. > > > Sorry to be blunt, I'm also trying to go self employed somehow and > > hopefully I will then be able to feel your pain more accurately. > > > Colin > > Hi Colin, > > If only it were so simple! I appreciate that software is supplied "as is" > which is why I had to shrug my shoulders when the bug caused me hassle th= e > first time it occurred in July 09. When it re-appeared in my next design = in > November 09 after allegedly being fixed and caused the PCBs to be written > off, that's when I started to feel somewhat aggrieved! Number One have sa= id > it's a different fault - just one with exactly the same symptoms (!!) so = I > shouldn't complain. I've approached them for some form of recompense or a= t > least a good will gesture but they won't even answer my e-mails now. > > The thread about this saga on their forum shows basic gist if you can be > bothered:http://www.numberone.com/forum/topic.asp?TOPIC_ID=3D385 > > I hear what you say about checking everything i.e. basically trust nothin= g! > Good luck if you go self-employed. Choose your tools supplier well though= , > not like me! > > Rog. I've never used EasyPC, but have had similar problems with PADS. The main problem is the disconnect between the design database and the Gerber output. Our company always does extensive post design checks before sending the Gerbers to fabrication. We also require the fab house to check the Gerbers to the IPC netlist generated directly from the PADS database. This is where this type of problem usually gets discovered. If the fab house only uses the IPC netlist to run electrical test after fabrication, you lose a lot of time and money. If you let the fab house run the electrical tests from the Gerbers without supplying an IPC netlist, then you can lose even more. Regards, GaborArticle: 145029
On 20 =D1=8F=D0=BD=D0=B2, 17:03, John_H <newsgr...@johnhandwork.com> wrote: > On Jan 20, 7:17=C2=A0am, Alex <vict...@gmail.com> wrote: > > > > > Hello All, > > > I am a beginner and want to get an idea how to construct actual FPGA- > > based design (a PCB) after this was developed and tested using > > development board (I use Xilinx Microblaze 1600E development board). > > > My understanding is that as my particular project uses just some of > > the features available on the development board (in my design these > > are RS232 port, FPGA chip, ADC, DAC, BNC connector for radiofrequency > > signal output) only these have to be constructed on my PCB - is this > > correct. > > I also will need to accomodate on my PCB a ROM where hardware > > configuration (which will be downloaded to FPGA chip each time when it > > is powered on) is saved. And I do not understand one thing here - this > > ROM obviously has to be programmed in advance in order to keep > > hardware configuration - is this programming normally done on a > > development board? > > > Thank you. Please feel free to comment on my questions and tell more > > (whatever you find relevant) about construction of FPGA-based designs > > for beginners - I am a beginner and interested to learn about any > > aspect of this. > > There is a great deal of superb information in the FPGA manufacturer's > data sheets and application notes. > > You need to pay close attention to power, ground, and decoupling but > your attachment to peripherals isn't dependent on how the demo board > was laid out as much as where you want things connected. =C2=A0There are > pins that are I/O, some pins might be input only, some are designed to > be used for clocking, and other special purpose pins might be > available. =C2=A0Know the part before you design a board. > > The memories are typically programmable in-system. =C2=A0If you read the > application notes further into the programming and memories, you'll > find that a programming adapter hooked up to the PC such as an Altera > Byteblaster or a Xilinx USB Platform Cable programmer will get you the > attachment you need to program the device when it's already soldered > on the board. =C2=A0If your demo board has the programming hardware built > in such that you don't have a stand-alone programmer AND the demo > board has sockets for at least one type of program memory, then yes: > you can program the memory in the demo board and transfer it to your > new board. > > Most designs I've been around have either on-board programmer hookups > for the stand-alone programming cables I mentioned or are programmed > by a processor that brings up the FPGA as part of the system boot. Hi John_H Thank you for reply and suggestion to read application notes first - this is a right approach, I agree.Article: 145030
On Jan 20, 11:37=A0pm, "Roger" <rogerwil...@hotmail.com> wrote: > "-jg" <jim.granvi...@gmail.com> wrote in message > > news:31d31451-4bcb-4f26-93ce-49c9346403a8@k19g2000yqc.googlegroups.com... > > > On Jan 20, 10:01 am, "Roger" <rogerwil...@hotmail.com> wrote: > >> This design had 3 vias that were again shorting Cu pour areas > >> within the board. > > > Does it not have a Post-pour clearance/connectivity check ? > > > I've also seen a PCB FAB's tool set (CAM350) drop the ball : if you > > give them Gerber FILL codes, CAM350 does not always quite get it > > right... > > > That's why you should NOT use too much intelligence in your Gerber > > data, and use your PCB tools checks.... > > (and a Mk1 =A0eyeball helps too ) > > Jim, > > The DRC tool checks the clearances and connectivity of the design within = the > EPC environment. The fault appears when the Gerber files are generated i.= e. > the Gerbers had the Cu touching the vias whereas this wasn't the case whe= n > still in the design environment. The DRC obviously reports no problems as= it > works within the EPC environment. ?! A good tool should use the SAME dataset for DRC, as it does for Gerber plotting. - in fact, it is usually MORE work, to do otherwise. Did you verify the Gerbers in a viewer ? > > Interesting what you say about the FILL codes, I've not heard of that > before. Yes, shows the risks of allowing a downstream tool, to generate copper data. Especially if that copper data is OUTSIDE the DRC process, and it drops the ball... Nett Result is exactly the same issue you hit: Pour areas with too much copper. (aka missing voids).. Fill codes have their place for padstacks, but NOT for larger copper areas, with voids, cutouts and what may be varying plot orders... -jgArticle: 145031
"-jg" <jim.granville@gmail.com> wrote in message news:b856ac87-c122-4222-b1b4-7ab0f4f61f34@14g2000yqp.googlegroups.com... > On Jan 20, 11:37 pm, "Roger" <rogerwil...@hotmail.com> wrote: >> "-jg" <jim.granvi...@gmail.com> wrote in message >> >> news:31d31451-4bcb-4f26-93ce-49c9346403a8@k19g2000yqc.googlegroups.com... >> >> > On Jan 20, 10:01 am, "Roger" <rogerwil...@hotmail.com> wrote: >> >> This design had 3 vias that were again shorting Cu pour areas >> >> within the board. >> >> > Does it not have a Post-pour clearance/connectivity check ? >> >> > I've also seen a PCB FAB's tool set (CAM350) drop the ball : if you >> > give them Gerber FILL codes, CAM350 does not always quite get it >> > right... >> >> > That's why you should NOT use too much intelligence in your Gerber >> > data, and use your PCB tools checks.... >> > (and a Mk1 eyeball helps too ) >> >> Jim, >> >> The DRC tool checks the clearances and connectivity of the design within >> the >> EPC environment. The fault appears when the Gerber files are generated >> i.e. >> the Gerbers had the Cu touching the vias whereas this wasn't the case >> when >> still in the design environment. The DRC obviously reports no problems as >> it >> works within the EPC environment. > ?! A good tool should use the SAME dataset for DRC, as it does for > Gerber plotting. > - in fact, it is usually MORE work, to do otherwise. > > Did you verify the Gerbers in a viewer ? > >> >> Interesting what you say about the FILL codes, I've not heard of that >> before. > > Yes, shows the risks of allowing a downstream tool, to generate copper > data. Especially if that copper data is OUTSIDE the DRC process, and > it drops the ball... > > Nett Result is exactly the same issue you hit: Pour areas with too > much copper. (aka missing voids).. > > Fill codes have their place for padstacks, but NOT for larger copper > areas, with voids, cutouts and what may be varying plot orders... > > -jg Jim, Are these the G36 and G37 codes? Rog.Article: 145032
On Jan 19, 1:51=A0pm, Mike Treseler <mtrese...@gmail.com> wrote: > rickman wrote: > > After struggling with VHDL type casting for some time, I finally > > settled on using signed/unsigned for the majority of the vectors I > > use. =A0I seldom use integers other than perhaps memory where it > > simulates much faster with a lot less memory. =A0But nothing is > > absolute. =A0I just try to be consistent within a given design. > > I use integer/natural ranges for small numbers > and signed/unsigned for large. Can you explain the idea behind that? Why integers for small numbers and not large? > > I have > > never used bit types, but the discussion here about the advantages of > > ulogic over logic is interesting. =A0I certainly like to speed up my > > simulations. =A0But it is such a PITA to get away from std_logic. > > Vectors, require some compromise. > I only use std_logic_vector for non-numeric variables > and for the device pins. > > For std_ulogic bits, there is no pain. > However the advantages are not overwhelming either. > > Simulators are now very well optimized for standard types, > and I would not expect much run-time speed up. As optimized as they may be, a signal that does not require resolution will take longer than one that does. Detecting multiple drivers is done at compile time while the resolution is done at simulation time. I guess if there are no multiple drivers the difference may not be apparent though. > Detecting multiple drivers at compile time is very useful > for new users using many processes, > but these errors can also be found at elaboration time. > > =A0 =A0 =A0 =A0-- Mike Treseler Yeah, I can't say I have many issues with multiple drivers. I'm pretty sure the tools I've been using give adequate warnings when I do make a mistake and reuse a signal name. RickArticle: 145033
hi,all
i have created an user ip connecting opb bus based microblaze.when i
watch the data from many ports in chipscope ,there is a strange Phenomenon.
i can obtain only one right data from the ports.but,the following samples
are in high state(FF e.g.) from all the ports.i can not solve the problem
all the time. who can
help me?
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 145034On Thu, 21 Jan 2010 05:54:10 -0800 (PST), rickman wrote: [Mike Treseler] >> I use integer/natural ranges for small numbers >> and signed/unsigned for large. > >Can you explain the idea behind that? Why integers for small numbers >and not large? Can't speak for Mike, but my reasoning might be: integers are convenient because they allow mixing of signed and unsigned quantities, and all the sign extension and range checking gets sorted out for me automatically; but VHDL integers (inexcusably, for any time later than about 1990) don't support anything wider than 31 bits. Yes, 31, that's not a typo for 32; you can't reliably get 32-bit signed behaviour from VHDL integers, and you can't get 32-bit unsigned behaviour at all. Madness, and one of my top beefs with VHDL. Beyond 31 bits, the signed and unsigned types work well and don't put any insuperable obstacles in my way; but mixing signed and unsigned is tedious, and it's also irritating that you can't copy an integer number or expression directly into a signed or unsigned vector, because VHDL doesn't allow overloading of the assignment operator. My personal choice tends to be driven by whatever looks neatest in the specific application I have to hand; any cracks can easily be papered-over by creating some appropriate VHDL functions. >As optimized as they [data types in library ieee] may be, a > signal that does not require resolution >will take longer than one that does. Detecting multiple drivers is >done at compile time while the resolution is done at simulation time. >I guess if there are no multiple drivers the difference may not be >apparent though. Right, a simulator can (and should!) optimise away the resolution function when only one driver exists on a signal. I suspect the need to support multi-valued logic is a bigger cost of CPU power than the resolution function, in many cases. No U/X/Z to worry about in an integer! >> Detecting multiple drivers at compile time is very useful >> for new users using many processes, >> but these errors can also be found at elaboration time. And also by synthesis tools. When writing HDL code that aims to be synthesisable, it's a smart move to synthesise it early in the debug process - just as soon as you've got the syntax goofs out of it. Synthesis tools do a lot of pretty smart static analysis and, obviously, can check for synthesis design rules that are of no concern to simulators. Some simulators have a "synthesis rule check" option on their compilers, but I've never found those to be useful; they miss far too much. >Yeah, I can't say I have many issues with multiple drivers. I'm >pretty sure the tools I've been using give adequate warnings when I do >make a mistake and reuse a signal name. Sure, but you can easily end up with syntactically legal - and perfectly meaningful - code that drives a signal from more than one process, and waste a lot of debug time as a result. In fairness, that tends to be more of a beginner's problem; the old hands around here probably get that sort of thing right first time, more often than not. -- Jonathan BromleyArticle: 145035
On Jan 21, 9:17=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Thu, 21 Jan 2010 05:54:10 -0800 (PST), rickman wrote: > > [Mike Treseler] > > >> I use integer/natural ranges for small numbers > >> and signed/unsigned for large. > > >Can you explain the idea behind that? =A0Why integers for small numbers > >and not large? > > Can't speak for Mike, but my reasoning might be: integers are > convenient because they allow mixing of signed and unsigned > quantities, and all the sign extension and range checking > gets sorted out for me automatically; but VHDL integers > (inexcusably, for any time later than about 1990) don't > support anything wider than 31 bits. =A0Yes, 31, that's not > a typo for 32; you can't reliably get 32-bit signed > behaviour from VHDL integers, and you can't get 32-bit > unsigned behaviour at all. =A0Madness, and one of my top > beefs with VHDL. > > Beyond 31 bits, the signed and unsigned types work well > and don't put any insuperable obstacles in my way; but > mixing signed and unsigned is tedious, and it's also > irritating that you can't copy an integer number or > expression directly into a signed or unsigned vector, > because VHDL doesn't allow overloading of the > assignment operator. > > My personal choice tends to be driven by whatever looks > neatest in the specific application I have to hand; > any cracks can easily be papered-over by creating some > appropriate VHDL functions. > > >As optimized as they [data types in library ieee] may be, a > > signal that does not require resolution > >will take longer than one that does. =A0Detecting multiple drivers is > >done at compile time while the resolution is done at simulation time. > >I guess if there are no multiple drivers the difference may not be > >apparent though. > > Right, a simulator can (and should!) optimise away the resolution > function when only one driver exists on a signal. =A0I suspect the > need to support multi-valued logic is a bigger cost of CPU power > than the resolution function, in many cases. =A0No U/X/Z to worry > about in an integer! > > >> Detecting multiple drivers at compile time is very useful > >> for new users using many processes, > >> but these errors can also be found at elaboration time. > > And also by synthesis tools. =A0When writing HDL code that > aims to be synthesisable, it's a smart move to synthesise > it early in the debug process - just as soon as you've > got the syntax goofs out of it. =A0Synthesis tools do a lot > of pretty smart static analysis and, obviously, can check > for synthesis design rules that are of no concern to simulators. > Some simulators have a "synthesis rule check" option on their > compilers, but I've never found those to be useful; they miss > far too much. > > >Yeah, I can't say I have many issues with multiple drivers. =A0I'm > >pretty sure the tools I've been using give adequate warnings when I do > >make a mistake and reuse a signal name. > > Sure, but you can easily end up with syntactically legal - and > perfectly meaningful - code that drives a signal from more than > one process, and waste a lot of debug time as a result. =A0In > fairness, that tends to be more of a beginner's problem; the > old hands around here probably get that sort of thing right > first time, more often than not. > -- > Jonathan Bromley On Jan 21, 7:54 am, rickman <gnu...@gmail.com> wrote: > As optimized as they may be, a signal that does not require resolution > will take longer than one that does. Detecting multiple drivers is > done at compile time while the resolution is done at simulation time. > I guess if there are no multiple drivers the difference may not be > apparent though. As Jonathan alluded, many simulators have a default optimization (can be turned off) that, assuming all resolution functions are transparent (meaning that the result of the resolution of a single driver is always the value of that single driver) omit the resolution function when only one driver is present. Of course, the resolution function for std_logic is transparent, but resolution functions are not required to be that way by the LRM. I have seen such non-transparent resolution functions used in a library used for modelling performance of systems with resource contention, etc. As I recall, the arbitration scheme used a non-transparent resolution function on the record type that represented a bus. However, for std_logic, there is often no simulation penalty, but perhaps a small elaboration phase penalty. Integer arithmetic promotes results to at least 31 bit signed, and only limits them upon assignment to a smaller subtype's range. Thus the result of a natural - 1 can be less than zero (just don't try to store it in a natural!), whereas the result of an unsigned - 1 cannot. The synthesis tools are smart enough to optimize out the logic from the intermediate promotion that is not needed. Integer arithmetic is MUCH faster to simulate than vector based arithmetic, even when using divide/modulo by powers of 2 to extract "bit fields" or truncate values. The divide/modulo with powers of 2 is automatically optimized by synthesis. Integer operations are usually implemented directly via the corresponding processor instruction, rather than the complex nature of dealing with individual MLV "bits" spread across different addresses in memory for a vector. The new fixed point package borrows some interesting features from integers, but not all of them. Note that the fixed point types can be used for integers by simply specifying non-negative index ranges. The fixed point operators promote the results to a size that is large enough to handle the largest possible result without overflowing, but they do not promote u_fixed to s_fixed for subtraction (an unfortunate oversight for arithmetic completeness, which could also be handled by the customary resizing). The general idea for using the fixed point system would be to let the operators promote intermediate values in expressions to preserve accuracy, then resize the final result to fit the size of the storage, the same way (conceptually) that is used for integers. AndyArticle: 145036
I am using Synplify Pro that came with Lattice ispLever and I am getting the following warning message... Initial value is not supported on state machine TTSuperCnt It points to the line starting the async reset section in the process defining the above signal. There is nothing wrong with the code I've written... at least nothing I haven't seen in any number of years using boiler plate case statement code for a signal like this (unsigned (2 downto 0)). Synplify says that this signal is a state machine of 3 states and I am trying to initialize it to one of the states it has detected. I'm wondering if Synplify, on deciding this is a state machine, treats the state assignments as it's "property" and does not want me to assign it at startup. But that makes no sense. I guess since it is a warning, perhaps it is ok to ignore, but I'm not sure if it is assigning an initial value or not??? It gives the same warning for several signals in several modules. Is anyone more familiar with this warning? RickArticle: 145037
On Jan 21, 3:11=A0pm, rickman <gnu...@gmail.com> wrote: > I am using Synplify Pro that came with Lattice ispLever and I am > getting the following warning message... > > Initial value is not supported on state machine TTSuperCnt > > It points to the line starting the async reset section in the process > defining the above signal. =A0There is nothing wrong with the code I've > written... at least nothing I haven't seen in any number of years > using boiler plate case statement code for a signal like this > (unsigned (2 downto 0)). =A0Synplify says that this signal is a state > machine of 3 states and I am trying to initialize it to one of the > states it has detected. > > I'm wondering if Synplify, on deciding this is a state machine, treats > the state assignments as it's "property" and does not want me to > assign it at startup. =A0But that makes no sense. =A0I guess since it is = a > warning, perhaps it is ok to ignore, but I'm not sure if it is > assigning an initial value or not??? =A0It gives the same warning for > several signals in several modules. > > Is anyone more familiar with this warning? > > Rick Here is a clue... A similar signal that is defined as an enumerated type is also detected as a state machine, but does not get the initialization warning. It is being initialized to one of the enumerated values. So perhaps any state machine it detects is treated as an enumerated type and the tool is not bright enough to translate the initialization value to one of the enumerated states. But if you define it as an enumerated type, the initial value doesn't give heartburn. RickArticle: 145038
I guess I never looked to closely at how Synplify handles state machines. I found another one that is just a three bit counter that is controlling a sine wave table lookup. I set it up in a case statement to count 0 up to 3 then 7 down to 4. This lets me look at just the two lsbs for the table index since the table is used twice for one cycle of the sine wave. But Synplify has "optimized" the counter to a 1-hot counter of 8 bits! Hmmm... I guess as I think about it a bit, a given state of a 1-hot counter is deocded by looking at one bit. Since each value from the table is used in two positions of the cycle, it still only depends on two input bits. Since the 1-hot register uses no LUTs, perhaps this is a slightly more efficient implementation. I wouldn't have thought of that on my own. Have we reached the point where HDL tools are smarter than the designers??? It would explain a lot of the seemingly dumb stuff I see come out of the tools. It would mean I am just not smart enough to understand the impact of the code I am writing and the tool is producing the best it can given my lousy code! Geeze, I hope that's not the case!!! If it is, I think I need to retire. RickArticle: 145039
I've been trying out the Icarus Verilog compiler/simulator. It looks nice so far. Any views on it? Also, it claims that it can generate code to load onto real FPGA's. Can it really do that? Has anyone tried it? I'm interested in Altera devices.Article: 145040
On Jan 22, 12:10=A0am, "Roger" <rogerwil...@hotmail.com> wrote: > Jim, > > Are these the G36 and G37 codes? Yes. Use them with caution, and I'd suggest NEVER for copper pour areas. Restrict them to purely local 'nn nested' type entities, like fonts, and pad-shapes. -jgArticle: 145041
All, Could someone point me to a board or boards that combine a modern FPGA with multiple ethernet PHYs? The only multiple-ethernet board that I have discovered is based on a V2P. Thank you in advance. StephenArticle: 145042
On Jan 21, 4:52=A0pm, rickman <gnu...@gmail.com> wrote: > I guess I never looked to closely at how Synplify handles state > machines. =A0I found another one that is just a three bit counter that > is controlling a sine wave table lookup. =A0I set it up in a case > statement to count 0 up to 3 then 7 down to 4. =A0This lets me look at > just the two lsbs for the table index since the table is used twice > for one cycle of the sine wave. =A0But Synplify has "optimized" the > counter to a 1-hot counter of 8 bits! > > Hmmm... I guess as I think about it a bit, a given state of a 1-hot > counter is deocded by looking at one bit. =A0Since each value from the > table is used in two positions of the cycle, it still only depends on > two input bits. =A0Since the 1-hot register uses no LUTs, perhaps this > is a slightly more efficient implementation. =A0I wouldn't have thought > of that on my own. =A0Have we reached the point where HDL tools are > smarter than the designers??? =A0It would explain a lot of the seemingly > dumb stuff I see come out of the tools. =A0It would mean I am just not > smart enough to understand the impact of the code I am writing and the > tool is producing the best it can given my lousy code! =A0Geeze, I hope > that's not the case!!! =A0If it is, I think I need to retire. > > Rick There are a few things the synthesizer will try to do to keep the designer from having to be too smart. State machines are a biggie but you'll also find memory inferences and removal of replicated logic never seem to follow with the original design intention. There's almost as much time spent keeping the compiler from doing things as there is trying to cajole the tool into producing the output that's *obvious* to the designer! When the synthesizer is designed to produce good results for even the poorest code, the better code sometimes suffers. If the compiler didn't try to do things different than you expect, that would indicate you write poor code. You don't so it does. At least until you learn how to push the rope more easily. The tools shouldn't present a challenge when compared to the algorithms and implementation. But they do. Know you're not alone. - John_HArticle: 145043
Hi. Are there such thing as FPGA farm (for cryptographical purposes), containing a lot of expensive FPGAs, and accessed remotely for some payment?Article: 145044
Stephen Depending on what specification you need we can certainly 10/100T multiple phys using our add-on modules for our boards. We are also looking at doing a gigabit phy solution as well but it's not done as yet. As an example look at the dil headers on http://www.enterpoint.co.uk/oem_industrial/mulldonnoch2.html which without accurately pin counting should take at least 5 and maybe 7 ethernet phy modules http://www.enterpoint.co.uk/moelbryn/modules/ethernet_= phy.html. These dil headers appear in a number of our products so you can do the same in other formats like PCI (Raggedstone1), PCIE (Broaddown4, Raggedstone2-to launch shortly) and so on. John Adair Enterpoint Ltd. On 22 Jan, 02:39, "stephen.cra...@gmail.com" <stephen.cra...@gmail.com> wrote: > All, > > Could someone point me to a board or boards that combine a modern FPGA > with multiple ethernet PHYs? =A0The only multiple-ethernet board that I > have discovered is based on a V2P. > > Thank you in advance. > > StephenArticle: 145045
Hi John, John_H <newsgroup@johnhandwork.com> writes: > When the synthesizer is designed to produce good results for even the > poorest code, the better code sometimes suffers. If the compiler > didn't try to do things different than you expect, that would indicate > you write poor code. You don't so it does. At least until you learn > how to push the rope more easily. For what definition of "poor" - do you mean code that would have been sub-optimal in terms of frequency or LUT usage *in the past*? "Poor" and "Better" (in my book) are about readability, maintainability and debuggability. Usually that is in direct opposition to clever synthesis tricks. So if I can write readable code and the synthesiser does a good job on my "poor" code, then I regard that as a win! Or did I misunderstand your comment? > > The tools shouldn't present a challenge when compared to the > algorithms and implementation. But they do. Know you're not alone. > Personally, I'm impressed that I can write a simple description of my logic and get a complicated near-optimal synthesis result out in a large number of cases - I wonder if I'm alone? :) Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 145046
Hi, everybody:
I'm confused with offset constraint and its report recently. Can anyone
help me? Thanks very much!
"din" is a input data whose bus width is 32bit. I set a offset
constraint :
Net "din<31>" offset = IN 2ns before clk_in. Period of clk_in was
constrained to 6ns. And i got a result in P&R report:
Constraint Request Actual
din<31>offset... 2ns -3.17ns
All constraints are met.
According to my comprehension, din<31> can lag 3.17ns mostly behind
rising edge of clk_in on the PAD. And after data path delay and clk path
delay, din<31> can be sampled at the first FF correcttly and exactly. Am i
right?
But if din<31> arrive 2ns before clk_in rising edge just as offset
constraint said, after delay of data path and clk path, clk rising edge
will present at nearly (2+3.17)ns with respect to din<31>, that is unstable
period of din<31>.
How to explain this?
Thanks, guys!
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 145047I have S3E starter kit. I accidentally connect a wrong power adaptor and two power regulators on the board was burnt. I cannot replace them because pads of the one of the regulators are under the package. So I decided to make or purchase a power supply card and connect it to starter kit. I have checked farnell.com and Linear Technology website but cannot find anything useful. Are there any power supply cards for FPGA's? Or any idea how I can re-operate my S3E board?Article: 145048
On Jan 22, 5:21=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote: > > For what definition of "poor" - do you mean code that would have been > sub-optimal in terms of frequency or LUT usage *in the past*? > > "Poor" and "Better" (in my book) are about readability, > maintainability and debuggability. =A0Usually that is in direct > opposition to clever synthesis tricks. =A0So if I can write readable > code and the synthesizer does a good job on my "poor" code, then I > regard that as a win! > > Or did I misunderstand your comment? Your definition of "better" fits pretty well but there's a little more to it. When there's little consideration made for how the hardware behaves with the Verilog tossed towards it, even very readable code can be a problem. Memory inferences want a properly clocked and enabled assignment for a single memory write and proper references for the memory reads; registers on the read address and/or read values are critical for proper implementation in a given target hardware. Flip- flops like single edges and usually either asynchronous set/reset controls or synchronous versions, not a mix (though a mix can be supported by pushing the synchronous controls behind LUTs into the logic). It's people who have never designed to the hardware level either with old TTL chips or coded with a dog-eared, printed copy of an FPGA architecture chapter that can produce something that looks okay from a software viewpoint - even readable - but will cause problems in clean synthesis. Clever synthesis tricks can be read, maintained, and debugged with ease when done well. Clever tricks not done well can be "poor" code, indeed. > Personally, I'm impressed that I can write a simple description of my > logic and get a complicated near-optimal synthesis result out in a > large number of cases - I wonder if I'm alone? :) A "simple description" in my book is one that's clean relative to the hardware. When I see code that's trying to use dual-clocked registers, case statements with (unintended) unpopulated states, unintended combinatorial latches, abuses of asynchronous data transfers or ugly workarounds to match pipelining, things get tough for compilers. But they usually still produce results. Clean, readable code designed to favor using a heavily loaded signal as close to the register as possible too often ends up with several levels of LUTs in the critical path despite synthesis timing constraints designed to keep those paths short. Synthesizers decide to do things different than the implied coding intent because they're smarter. Really? Too often I've had to manually piece-up a logic cone so the critical paths do what they should have from the beginning.Article: 145049
On Jan 22, 9:44=A0am, Din=E7ay Ak=E7=F6ren <din...@gmail.com> wrote: > I have S3E starter kit. I accidentally connect a wrong power adaptor > and two power regulators on the board was burnt. I cannot replace them > because pads of the one of the regulators are under the package. So I > decided to make or purchase a power supply card and connect it to > starter kit. I have checked farnell.com and Linear Technology website > but cannot find anything useful. Are there any power supply cards for > FPGA's? Or any idea how I can re-operate my S3E board? Where would you connect a "power supply card" if there was one? Repairing a board with burnt components can be difficult, often requiring an intense effort to pick out the burnt pieces of FR4 that can be unintentionally conductive. Even components with a pad underneath can be removed with a narrow focus heat gun, for instance. Even if you reflow nearby components, usually they're still in good shape afterward. Adding "dams" to block the airflow around more sensitive parts nearby can help when reworking in this manner. Do you know if your failed regulators have failed open? If you try to wire in another regulator such as a linear.com uModule, you need to make sure the parts still on board can play nice with the new supply.
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