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
"hrwieuyriwru" <jkshdfkjhskdjfksfksd@dfuosdf.com> wrote in message news:<WyHVa.696$il2.75461696@newssvr21.news.prodigy.com>... > "Subroto Datta" <sdatta@altera.com> wrote in message > news:qXuUa.3036$NV3.1143@newssvr31.news.prodigy.com... > > Multicycle paths are paths between registers that intentionally take more > > than one clock cycle to become stable. For example a register may need to > > trigger a signal every second or third rising clock edge. > > > > A False path is any path that is not relevant to a circuit's operation. > > > > A good description of both multicycle and false paths can be found in the > > following Timing Analysis App Note: > > > > http://www.altera.com/literature/an/an123.pdf > > > > Subroto Datta > > Altera Corp. > > From a conceptual standpoint, these definitions are mostly correct. > But be aware that different CAD-tool vendors (Synopsys, Cadence, > etc.) may treat the *operational* meanings of false-path differently.. > > In Synopsys's case, their application manuals have clear > examples when to use 'set_disable_timing' versus 'set_false_path.' > The problem with set_false_path is that it can (unintentionally) > affect more than just timing-constraints. > > > > > > > > > "LIJO" <lijo_eceNOSPAM@hotmail.com> wrote in message > > news:bftlvd$iao78$1@ID-159866.news.uni-berlin.de... > > > Hi, > > > Can anyone tell me what is Multi Cycle path and False path? > > > > > > thanks > > > Lijo > > > > > > > > > > > > > > > > > > Here are some examples I can think of. Lets say you have a mode bit that you use in your logic and you know some paths specifically do not exist when the core is not in that mode, that becomes a false path. Lets say, you do a complex logic such as a CRC and find that your final CRC evaluation takes more than one clock cycle (based on byte enables) and cannot meet the speed requirements. You can pipeline the data and calculate final CRC in multiple clock cycles. Open to learn more :-)Article: 58676
Isaac wrote: > 1. Do I have to define different input / output signal so that every > BLOCK has different signal names from each other and than use port map > and component decelartion in top *.vhd file to accopmlish the task. Read up on the VHDL generate statement. Here's a related example: http://groups.google.com/groups?q=generate+add_1_bit -- Mike TreselerArticle: 58677
> > I had the same experience: the PC parallel port HW wouldn't switch into EPP > > mode without the proper negotiation. You will stay in SPP mode on the SW > > side, though you can emulate the EPP protocoll from SW. And yes, it's slow. > > > > Andras Tantos > > Were you able to implement the proper negotiation and avoid staying in > SPP? If so what do you recommend? Unfortunately no, due to lack of time. I also had the poblem that I configured my FPGA through the same parallel port so I'm not sure if I could re-negoiate the protocol after configuration in my design at all. Andras TantosArticle: 58678
Hi, I'm trying to interface a Xilinx board (XC2V6000) with an Altera board (Apex20K1500E). The Xilinx board IO is at 1.8V while the Altera board IO is at 3.3V. Now if the Altera Vccint is tied to 1.8V, the Altera part can take inputs at 1.8, 2.5 and 3.3 V. Meanwhile, the output voltage of the Altera part is fixed to the Vccio voltage (3.3V on my Altera board). But it doesnt look like the Xilinx part can take the 3 different input voltage levels if its Vcco is tied to 1.8V. Is this true ? If so, I would be surprised that Xilinx doesnt have a feature that Altera has. So, I can take inputs from the Xilinx board, but cant provide 3.3V outputs from the Altera board to the Xilinx board. Any solutions ? Thanks, PrashantArticle: 58679
Hi, I'm designing a bus oriented processor peripheral chip using a XC2S100 / webpack 5.2 SP3 It went well until the chip was filled about 50% then strange trouble with the tristate buffers started to appear, leading to strange behaviour. I use these tri-state buffers only in the top level schematic diagram. Here are the symptoms : ------------------------- => ECS gives me this warning : Warning: Net "CPU_DI(15)" is connected to too many sources pins and/or IO ports. A Wired Or connection will be used. "CPU_DI" is a 16 bits bus with 4x16 bits sources, 4x8 bits sources on the upper half and 4x8 bits sources on the lower half, all controlled using BUFE buffers. => When compiling the design, I get the following warning/error messages : WARNING:Xst:528 - Multi-source in Unit <testio> on signal <cpu_di<15>> not replaced by logic Sources are: xlxi_492:o<15>, xlxi_895:o<15>, xlxi_340:o<7>, xlxi_849:do<15> ( ... same message for all 16 pins ... ) ERROR:Xst:415 - Synthesis failed => In the new RTL schematic viewer : I found that the lower part of the bus have been split in two seemingly unrelated entities. In the RTL schematics, the 16 bit connections refer to CPU_DI(15:0), while the 8 bits connections refer to a bus named "_n0131(7:0)" (this name does not appear anywhere in the original schematic diagram, nor in the ".vhf" file). ------------------------- I'm a bit confused by it ... What exactly makes ECS "think" that my bus is connected to "too many sources" ? how many sources can be connected to a bus through BUFE/BUFT buffers before this message appears ? Is it related to the way I control the BUFE's "Enable" input ? answer database #14264 says "in most cases, XST is able to determine when multiple drivers are illegal". How does it determine it ? Are they specific rules the tool expects us to follow when designing the mutually exclusive BUFE "enable" signals ? ------------------------- A solution could be to convert it all to multiplexers, but my goal with tri-state buffers was to reduce ressource usage. However, as you might guess, I would like to avoid this and learn how to properly use tri-state buffers in Spartan II. Any help would be appreciated, Eric.Article: 58680
Prashant, The reason why we "do not have this feature" is that the IO ESD cell required for that feature is a non standard cell design (ie not a foundry supported standard ESD IO cell). That said, there is nothing wrong with that (it has its advantages). But, a few years ago we decided that rather than be responsible for our ESD, we would prefer to use the foundry specific (and guaranteed) ESD solution. That lowers the capacitance (makes it faster) and has other advantages as well. Not to mention the ESD performance is wonderful. Now designing your own ESD is just fine, but everytime there is any little process change, you have to re-qualify the ESD protection performance. The area is also larger. And guess who pays for area? Lets see: performance, worse; ESD, worse; Area, larger; can be driven with voltages >> Vcco. Our features: better performance, better ESD, smaller area, Vin < Vcco. To be compatible with a driver that pulls to a voltage higher than Vcco, you need some series resistance to drop the voltage (and limit the current). We recommend not sourcing more than 10 mA per input (for signal integrity reasons, the diodes will handle ampere transients). Their part also allows for lower IO voltages, by using 1.8V on the bank that has the drivers in it, so that would be the prefered approach. Or you can up the Vcco voltage on one of our banks to 3.3V. Austin Prashant wrote: > Hi, > > I'm trying to interface a Xilinx board (XC2V6000) with an Altera board > (Apex20K1500E). The Xilinx board IO is at 1.8V while the Altera board > IO is at 3.3V. Now if the Altera Vccint is tied to 1.8V, the Altera > part can take inputs at 1.8, 2.5 and 3.3 V. Meanwhile, the output > voltage of the Altera part is fixed to the Vccio voltage (3.3V on my > Altera board). But it doesnt look like the Xilinx part can take the 3 > different input voltage levels if its Vcco is tied to 1.8V. Is this > true ? If so, I would be surprised that Xilinx doesnt have a feature > that Altera has. > > So, I can take inputs from the Xilinx board, but cant provide 3.3V > outputs from the Altera board to the Xilinx board. Any solutions ? > > Thanks, > PrashantArticle: 58681
Hi, I am trying to map some modules in my design into different regions on an FPGA (XC2V250). I also wish that the AREA_GROUP that is designated for a particular instance does NOT contain any other logic. Is there a way to do this? I have tried using the AREA_GROUP constraint, but it does not prevent ungrouped logic from being mapped into the region assigned to an area-group. I looked through the Constraints guide that Xilinx provides. It says that such a behavior can be obtained for modular design flow. Does that mean I will need to unnecessarily use a modular design flow (although I have all the module descriptions ready with me, and my design is not really very big). Please tell me if there is a simpler way. regards, AmanArticle: 58682
"Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message news:3F282CEE.521DD3E1@xilinx.com... > The reason why we "do not have this feature" is that the IO ESD cell > required for that feature is a non standard cell design (ie not a foundry > supported standard ESD IO cell). Thanks for the explanation. It's the first time I've heard it in adequate detail. However, you should know that it has cost you at least two designs that I know of.Article: 58683
Austin Lesea <Austin.Lesea@xilinx.com> writes: > Hyperlynx handles connectors, daughter cards, etc. It just gets complex, which is not so much of a problem, as it is reality. The web site and data sheet look great. But what input formats for the PCB design do they support? Any open formats? I use Eagle, which isn't listed. I wouldn't mind writing a translator to some other open format if necessary, but if they only support proprietary formats it won't do me any good. And what does a single-user license for Hyperlynx EXT cost?Article: 58684
"Ray Cheung" <cccheung@cse.cuhk.edu.hk> wrote in message news:1059236649.547176@eng-ser4... > There is a short and good example on multi-cycle path. Thanks. > http://www.saros.co.uk/hdlsolutions/appsnotes/leonardo/SAN001.pdf That does seem to be a good explanation. I was almost thinking that they were still going to latch the data every clock cycle, and depend on the delay through the logic. That is, the delay through the combinatorial logic was guaranteed to be more than three clock cycles, and less than four, with new data entered every clock cycle, and results latched every clock cycle. It is my understanding that some of Cray's machines did something like that. There are descriptions of PC board traces intentionally longer to delay signals. I don't believe, though, that it would work well with FPGA's. It only works if you know the gate delay very accurately. Many intel processors used dynamic logic, which I believe is registers that store data in capacitors such that they have a minimum clock frequency. -- glenArticle: 58685
Pete, We win some, we lose some. You never know what "feature" (or latent bug) will be the deciding factor. But thanks for the feedback. I was well aware of the issue and the tradeoffs. If folks want that 5V input tolerance without limiting resistors, they can still buy Xilinx and use Spartan II, or Virtex. Austin Pete Fraser wrote: > "Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message > news:3F282CEE.521DD3E1@xilinx.com... > > > The reason why we "do not have this feature" is that the IO ESD cell > > required for that feature is a non standard cell design (ie not a foundry > > supported standard ESD IO cell). > > Thanks for the explanation. It's the first time I've > heard it in adequate detail. > > However, you should know that it has cost you > at least two designs that I know of.Article: 58686
Eric, All these questions are best answered by Mentor/HyperLynx. I just don't know all of those details I think we can extract from the Gerber files, but I am not sure. Austin Eric Smith wrote: > Austin Lesea <Austin.Lesea@xilinx.com> writes: > > Hyperlynx handles connectors, daughter cards, etc. It just gets complex, which is not so much of a problem, as it is reality. > > The web site and data sheet look great. But what input formats for the > PCB design do they support? Any open formats? I use Eagle, which isn't > listed. I wouldn't mind writing a translator to some other open format > if necessary, but if they only support proprietary formats it won't do > me any good. > > And what does a single-user license for Hyperlynx EXT cost?Article: 58687
> One additional source of info would be to get the fab costs for the > 8"/12" wafers from say TSMC or UMC and try to figure the production > costs of your FPGA and possibly your own design committed to an ASIC > directly for comparison. > > I am not saying this is easy... You can say that again -- I don't think it's possible for anyone outside the operations/product engineering groups of an FPGA company to compute the cost of FPGA fabrication. You need to know (a) wafer prices (b) mask costs (ammortized over # of chips produced) (c) defect density vs. demand over product lifetime (d) die sizes (e) suceptability to defects (f) repair rates (for Altera parts w/redundancy) (e) development/support/software costs (ammortized over products sold) etc. And because big FPGA manufacturers are some of the largest fab customers/partners, I'd guess they don't pay list price... Regards, - Paul Leventis Altera Corp.Article: 58688
Go to Altera's web site or do a google search. Lev Razamat wrote: > If anybody have a chematic of the ALTERA Byte Blaster II. Or if anybody can > send me link to this schematic > > Thanks in advance > > Lev > > -- Marc Guardiani To reply directly to me, use the address given below. The domain name is phonetic. fpgaee81-at-eff-why-eye-dot-netArticle: 58689
Since you're doing schematics with tristate buffers in them, you need to consider a bug in 5.x that will not be fixed until 6.1i. Iterated instances of IOBUFs and BUFTs are processed incorrectly. A dummy net is created then not connected to the buffer. The only work-around is to hand edit the HDL output of the synthesized schematic. Eric wrote: > Hi, > > I'm designing a bus oriented processor peripheral chip using a XC2S100 / > webpack 5.2 SP3 > > It went well until the chip was filled about 50% then strange trouble > with the tristate buffers started to appear, > leading to strange behaviour. > I use these tri-state buffers only in the top level schematic diagram. > > > Here are the symptoms : > ------------------------- > > => ECS gives me this warning : > Warning: Net "CPU_DI(15)" is connected to too many sources pins and/or > IO ports. A Wired Or connection will be used. > > "CPU_DI" is a 16 bits bus with 4x16 bits sources, 4x8 bits sources on > the upper half and 4x8 bits sources on the > lower half, all controlled using BUFE buffers. > > => When compiling the design, I get the following warning/error messages : > > WARNING:Xst:528 - Multi-source in Unit <testio> on signal <cpu_di<15>> > not replaced by logic > Sources are: xlxi_492:o<15>, xlxi_895:o<15>, xlxi_340:o<7>, xlxi_849:do<15> > ( ... same message for all 16 pins ... ) > ERROR:Xst:415 - Synthesis failed > > => In the new RTL schematic viewer : > > I found that the lower part of the bus have been split in two seemingly > unrelated entities. > In the RTL schematics, the 16 bit connections refer to CPU_DI(15:0), > while the 8 bits connections refer to a bus > named "_n0131(7:0)" (this name does not appear anywhere in the original > schematic diagram, nor in the ".vhf" file). > > > ------------------------- > > I'm a bit confused by it ... > > What exactly makes ECS "think" that my bus is connected to "too many > sources" ? > how many sources can be connected to a bus through BUFE/BUFT buffers > before this message appears ? > Is it related to the way I control the BUFE's "Enable" input ? > > answer database #14264 says "in most cases, XST is able to determine > when multiple drivers are illegal". > How does it determine it ? > Are they specific rules the tool expects us to follow when designing the > mutually exclusive BUFE "enable" signals ? > > ------------------------- > > A solution could be to convert it all to multiplexers, but my goal with > tri-state buffers was to reduce ressource > usage. However, as you might guess, I would like to avoid this and learn > how to properly use tri-state buffers in > Spartan II. > > Any help would be appreciated, > > Eric. > -- Marc Guardiani To reply directly to me, use the address given below. The domain name is phonetic. fpgaee81-at-eff-why-eye-dot-netArticle: 58690
"Jason Berringer" <look_at_bottom_of@email.com> wrote in message news:IlGVa.3393$mv6.617644@news20.bellglobal.com... > Here is the code (after my text) instead of an attachment in case others > cannot read it. > > It takes (or should take) 20 to 21 clock cycles to get the data from the > input to the output. I put a few numbers through the simulation the only > correct values are 0 and 1, all other tested were incorrect. I'm pretty sure > it's a simple error that I'm not catching, I just can't see it at present. > Most of the stuff that I have done has been a bit more simple than this. The > algorithm works from a sample I've seen (no code just an explanation). Start > by shifting the most significant bit of your binary number into the least > significant bit of your "units" bcd value, when the number in the "units" > value is 5 or greater add 3 to it. Shift again, if the value is 5 or greater > add 3 to it, the values will continue to spill over to the "tens", > "hundreds", "thousands", etc. You must add 3 to each of the bcd digits if > any is five or greater, by the last shift (same number of shifts as your > input binary value (in my case 20 bits)) you'll have the bcd representation. > The example I mentioned above was for a microcontroller. As I said, I read Verilog much better than VHDL. I didn't even notice the loop yesterday, which is why I didn't think it was complicated enough. OK, thought for today: (snip) > elsif rising_edge(clk) then Does the following generate a gated clock? > if shift_en_s = '1' then The following statement must be done before the rest. While simulators may execute them in order, synthesized logic tends to execute them all at the same time. > bcd_value := bcd_value(22 downto 0) & ser_out_s; > bcd_out_s <= bcd_value; Does this generate a gated clock? Can you do it in traditional synchronous logic form, where either the previous contents, or the contents with "0011" added are loaded back in? (Also with the shift_en_s enable.) > if bcd_value(3 downto 0) >= "0101" then > bcd_value(3 downto 0) := bcd_value(3 downto 0) + "0011"; > end if; (snip) Gated clocks are especially hard in FPGA's. -- glenArticle: 58691
Thad Smith wrote: I'm following up my own post for a correction. > Assuming that the DAC is updated once each cycle of the output > frequency, you want your frequency to be within f (1 +- 1/3600), which > would generate the maximum phase error, assuming that the phase was > exactly matched at the beginning. That suggests that you want at least > a 12-bit converter. 12 bits should be sufficient for the full scale frequency. Since the OP said he needed to track 1 to 50 Hz with 0.1 degree max phase error, he will need an additional 6 bits to get the required resolution at the low end (1 Hz). Note that 18 bits of accuracy aren't needed -- only 18 bits of resolution, because of the feedback. The resolution could be achieved with 2 10 bit or 12 bit converters. > If you did external filtering, you could use fewer bits and toggle the > DAC setting more frequently such that the average voltage is for the > correct frequency. This is still true and could be used instead of another converter. ThadArticle: 58692
Austin Lesea <Austin.Lesea@xilinx.com> writes: > All these questions are best answered by Mentor/HyperLynx. Sure. I was hoping someone might email me some rough idea on the price before I waste a bunch of time trying to pry useful information loose from a salesgoon. Lord knows that all manner of unspeakable disasters would occur if companies actually put content like that on their web sites.Article: 58693
Thad - sounds good in theory - but there has never been a 12 bit DAC with 12 bits of reality - the LSB is junk with power supply noise and non-linearity. The 12 bit DACs are really capable of 11 - 11.3 bits with GOOD (excellent) gound planes and linear regulators and a cold plate for temperature stability. The phase error means that his load into the m and n integer will not do well in this application - they only increment on cross. I would suggest going to a full digitally done output using the dac and integrating it a little (time constant ~ 1/2 the update rate). The phase error budget here will kill him . Andrew Thad Smith wrote: >Thad Smith wrote: > >I'm following up my own post for a correction. > > > >>Assuming that the DAC is updated once each cycle of the output >>frequency, you want your frequency to be within f (1 +- 1/3600), which >>would generate the maximum phase error, assuming that the phase was >>exactly matched at the beginning. That suggests that you want at least >>a 12-bit converter. >> >> > >12 bits should be sufficient for the full scale frequency. Since the OP said he needed to >track 1 to 50 Hz with 0.1 degree max phase error, he will need an additional 6 bits to get >the required resolution at the low end (1 Hz). Note that 18 bits of accuracy aren't >needed -- only 18 bits of resolution, because of the feedback. The resolution could be >achieved with 2 10 bit or 12 bit converters. > > > >>If you did external filtering, you could use fewer bits and toggle the >>DAC setting more frequently such that the average voltage is for the >>correct frequency. >> >> > >This is still true and could be used instead of another converter. > >Thad > >Article: 58694
I have a project that needs a 21.48MHZ clock input. But the problem is that I dont have that type of oscillator. As the project is going to be in an large FPGA , is it possible to generate using coregen and a 40MHZ square source(the FPGA clock), a dds with adequate resolution and that at a certain phase increment, would in turn generate the 21.48MHZ needed but as a sinusoid. Now, in order to complete the design, the signal would remain in the digital domain and pass through some clipping logic, which would give a '1' when the sine value is greater than an arbritrary index. At the output of this block, we would theoretically have a square wave. The only inconvenience is that the generated square wave would be one that doesn't possess a 50% duty cycle. Could we use the available DLL to reconstruct the clock, based from the just created pseudo clock from the DDS? The tool used is coregen and we have a virtex 2 platform. I would really appreciate some clues about this idea. Thanks. JacArticle: 58695
Jean-Luc, To simulate, either do a functional sim prior to synthesis or do a timing simulation using the VHDL/Verilog netlist generated after place and route.A step by step description can be found in: http://www.altera.com/support/software/nativelink/simulation/modelsim/eda_vi ew_using_msim.html - Subroto Datta Altera Corp. "Jean-Luc" <nagel@computer.org> wrote in message news:b5a538f6.0307300636.2e61513b@posting.google.com... > Hello, > > I am designing a circuit for an Apex20ke FPGA with Synopsys v2001.8 > and Quartus2. > After compilation I want to simulate the design in ModelSim 5.5e. > Therefore I saved the current design using: > > write -format v -hierarchy -output top.v > write_sdf -version 2.1 top.sdf > > In ModelSim I could compile fine the verilog netlist but could not > load it due to an enormous number of errors such as: > > # Region: :top:I0:I1 > # Searched libraries: > # work > # ERROR: /pe_users/nagel/vhdl/smartcam/synopsys_linux/top.v(40686): > Instantiation of 'ATBL_1' failed (design unit not found). > > Now I included a number of libraries from Altera in my work library: > > lpm > altera_mf > apex20ke > > But these ATBL_* - that are in the apex20ke-3.db library (as reported > by report_library) - are still not found... > > Any help would be highly appreciated ! > > Thank you, > Jean-LucArticle: 58696
Hi Jacques: I think putting a Fox or Epson type oscillator on would be cheaper (no gates burned) and quicker than doing this, might be a fun excercise, but you are going to have to implement external dacs for this one - I don't think that Xilinx is prepared to enter the analog world, and a dds with the resolution you need is going to require a couple of fast dacs. Andrew Jacques athow wrote: >I have a project that needs a 21.48MHZ clock input. But the problem is >that I dont have that type of oscillator. As the project is going to >be in an large FPGA , is it possible to generate using coregen and a >40MHZ square source(the FPGA clock), a dds with adequate resolution >and that at a certain phase increment, would in turn generate the >21.48MHZ needed but as a sinusoid. > >Now, in order to complete the design, the signal would remain in the >digital domain and pass through some clipping logic, which would give >a '1' when the sine value is greater than an arbritrary index. At the >output of this block, we would theoretically have a square wave. The >only inconvenience is that the generated square wave would be one that >doesn't possess a 50% duty cycle. > >Could we use the available DLL to reconstruct the clock, based from >the just created pseudo clock from the DDS? > >The tool used is coregen and we have a virtex 2 platform. >I would really appreciate some clues about this idea. > >Thanks. >Jac > >Article: 58697
Hi Jason, First off, that's a pretty cool little algorithm... had to prove to myself that it worked. Let digit = 5 + n, where n = 0..4. We want new_digit = (digit * 2 + shift_in) % 10 = (5 * 2 + n * 2 + shift_in) % 10 = n * 2 + shift_in. If we add three, and wrap around at 16 (since 4-bit representation) then we get ((8 + n) * 2 + shift_in) % 16 = 2 * n + shift_in. I'm not sure that I've found the problem with your code, but there were a number of stylistic issues and one suspicious fragment I figured I'd point out. I'll add a caveat that I haven't really coded up any VHDL in a year or so, and prior to that my experience was mostly with structural VHDL. And I didn't have a compiler handy to try out my ideas. So I imagine I'll find out I'm wrong and learn something in the process! (0) I think the first problem is a lack of comments... uncommented code is always wrong :-) (1) Process #3. I hate variables. Especially variables mixed with signals... you must be very disciplined when using variables (I only use them in for loops...). So I honestly don't know what the code will translate into, as you are assigning a value to variable, then assigning to the variable to a signal, then changing the value of the variable. I'm not sure if the scheduled signal assignment occurs before or after the change in variable value. Also, I'm not sure that the variable turns into a register (i.e. has memory) -- either way though, it's not what you want. If it does become a register, then have 2 24-bit registers (unnecsessary/may not work). If you don't, then I don't know what will happen. Regardless, I think you want to first be adding three, THEN shifting. There are two ways I can think of restructuring this code into something that may work (see below). The first replaces your variable with a signal that is computed combinationally outside of the process. The second is an attempt to still use a variable, based on my limited understanding of this VHDL construct. Note that neither requires the asynchronous condition (though I'm thinking it may need an aclr for bcd_out_s...). if clk = '1' and clk'event then if load_data = '1' then bcd_out_s <= (OTHERS => '0'); elsif shift_en_s = '1' then bcd_out_s <= bcd_out_modified_s(22 downto 0) & ser_out_s; end if; end if; ... bcd_out_modified_s(3 downto 0) <= bcd_out_s(3 downto 0) + "0011" when bcd_value(3 downto 0) >= "0101" else bcd_value(3 downto 0); ... or: if clk = '1' and clk'event then if load_data = '1' then bcd_out_s <= (OTHERS => '0'); elsif shift_en_s = '1' then bcd_value := bcd_out_s; if bcd_value(3 downto 0) >= "0101" then bcd_value(3 downto 0) := bcd_value(3 downto 0) + "0011"; end if; ... bcd_out_s <= bcd_value(22 downto 0) & ser_out_s; end if; end if; I'm sure there are other ways to structure the code, and my way may add an additional clock cycle or may need an extra bit in the register to work right, but you get the idea. (2) Process #3 makes use of an asynchronous clear on the condition of load_data. If you can do something synchronously instead of asynchronously, you should. There's no harm in putting another if clause in your clocked portion of the process to cover the clear while loading case. (3) Process #2. You have two if statements, both of which affect bin_in_s: if load_data = '1' then bin_in_s <= data_in; end if; if shift_en_s = '1' then bin_in_s <= bin_in_s(18 downto 0) & '0'; end if; While legal, the interpretation (I think) is the same as the following code, which is cleaner and thus less likely to be incorrect. My experience is whenever I try to be as smart as the compiler, I end up getting bitten by it later... if shift_en_s = '1' then bin_in_s <= bin_in_s(18 downto 0) & '0'; elsif load_data = '1' then bin_in_s <= data_in; end if; (4) Process #1 & #4. You are instantiating many more registers than necessary. You could get away without the data_out register (unless you want to be able to process new data while some other chip takes its time reading your result, which seems unlikely). Also, you are inserting an extra cycle of latency with your data_ready & data_out registers. But there should be nothing functionally wrong there. (5) Your asynchronous reset may not be safe. The topic of many discussions. Not the problem you're having now I bet. Good luck, Paul LeventisArticle: 58698
>output of this block, we would theoretically have a square wave. The >only inconvenience is that the generated square wave would be one that >doesn't possess a 50% duty cycle. Why wouldn't it be (close to) 50% duty cycle? How close do you need? If you do the clipping with an inverter and AC couple the sine wave to the input and bias the input with a big resistor feeding back from the output, there is feedback on the bias that wil set the clipping level to make a 50% duty cycle output. I'm not sure how well that works at high speeds. It works fine at anything that isn't pushing the inverter very hard. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 58699
rickman <spamgoeshere4@yahoo.com> writes: > Jonathan Bromley wrote: > > Grin. > > > > Find yourself a civilised editor with a block/column select and > > fill facility. On Windoze we generally use TextPad, which is > > pretty goodand can be had in a free eval version if you don't > > mind the nag screens: > > www.textpad.com > > > > Or NEdit on Unix/Linux. > > Just my two cents worth on the editor for comments. CodeWright is not > free, and it is not even real cheap the last time I looked, but it is > very good. It has programmable comment definitions for different file > types. It also have a generic "Prompted Slide In" and out. This lets > you insert or remove anything you want at the start of each line in a > range. The only thing you need to specify is the text to insert or > remove. > > But I agree that it is down right silly that they don't have block > comments in VHDL. To quote Dr. Phil, "What were they thinking"? > I used to use CW, but IMHO the only editor to use for VHDL is Emacs with its VHDL mode. When I first switched, I worried about the column-select being a bit wacky, but now I have VHDL-mode and the other feature sof Emacs, I find that I don't actually need to column select anymore. I have heard good things about TurboWriter (which is stuff on top of CodeWright) - see http://www.saros.co.uk/index.htm?http%3A//www.saros.co.uk/hdlsolutions/products/index.shtml. Just my tuppence! Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conekt
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