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
Hi, this is a "public backup" of a holiday project maybe it's of use to someone: https://drive.google.com/file/d/0B1gLUU8hXL7veXVmZDhURGJ0N3c/edit?usp=sharing - "medium" ZPU processor - instantiated BRAM and upload of program code via DATA2MEM. Re-compiling the C-code and uploading a new bitstream takes about three seconds, which isn't too bad (I use Xilinx' platform cable USB; the Saturn V3 should also support xc3sprog upload by itself) - basic LPDRAM access as "proof-of-concept" using the Xilinx DRAM controller - basic VGA, connect with Dupont wires to an analog RGB monitor input - timing is met at the default 100 MHz clock - address decoder with support for zero-waitstate reads (i.e. from hardware registers) - performance is almost 1M 32-bit read/writes from DRAM per second, three times faster in internal BRAM. A speed demon in slow motion... - 9 % slice utilization (6 % LUT) on Spartan 6 LX45 --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157001
what is the prefered option of arithmetic operations using logic vectors and constant? convert logic vector to integer and do the operation or to convert the constant to logic vector? I have samples from A/D as logic vectors with some resolution and constants. I want to do arithmetic operations between them according to formula? if anyone has examples of such thing it will be very helpfull (VHDL). --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157002
On Mon, 18 Aug 2014 12:02:10 -0500 "itay" <101236@embeddedrelated> wrote: > what is the prefered option of arithmetic operations using logic vectors > and constant? convert logic vector to integer and do the operation or to > convert the constant to logic vector? > > I have samples from A/D as logic vectors with some resolution and > constants. I want to do arithmetic operations between them according to > formula? > if anyone has examples of such thing it will be very helpfull (VHDL). > > > > --------------------------------------- > Posted through http://www.FPGARelated.com std_logic_vectors don't do math. They only hold bits. If they're doing math, you're using some library that you shouldn't be, like std_logic_arith. Unsigned/signed do in fact do math, and typecast from std_logic_vector. You'll find them in numeric_std. They're useful for doing math when you: a) Need to be concerned about non-binary values such as 'X' and '-' b) Specifically want the overflow rollover behavior on add/subtract c) Have to deal with numbers outside the range +/-(2**31 - 1) Integers are fundamentally better than unsigned/signed in simulation. They're faster, you can ascribe specific bounds to them, and when you're working with them they need less syntax (as opposed to getting in and out of them, which is a whole other story). I prefer to use integers where possible, and fall back to signed/unsigned for the above reasons when I have to. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 157003
On Monday, August 18, 2014 12:27:48 PM UTC-5, Rob Gaddi wrote: > std_logic_vectors don't do math. They only hold bits. If they're doing ma= th, you're using some library that you shouldn't be, like std_logic_arith.= =20 As of the 2008 standard, the ieee.numeric_std_unsigned package extends arit= hmetic and relational operators, with an unsigned interpretation, to std_lo= gic_vector. It also contains conversion functions for natural/std_logic_vec= tor. If you need signed arithmetic, then you need to use either numeric_std.sign= ed. You can also use the ieee fixed point packages (sfixed type), with zero= or more fractional bits. sfixed has the benefit of automatically expanding= the result range/precision to handle the maximum/minimum arithmetic result= , and can be configured for saturation and rounding logic on resize.=20 As for the use of integer or signed constants, my preference when defining = a numerical value is to use integer if within integer'range. If using sfixe= d, then real constants are useful. Real/integer values can be added to sfix= ed/signed quantities automatically (the scalar operand is converted to sign= ed/sfixed of same range/precision as the vector operand). 2008 also provides a floating point library in 2008, with configurably size= d mantissa and exponent. AndyArticle: 157004
Hi, if anybody else runs into the same problem with an FPGA module: xc3sprog failed to upload the bitstream to a Spartan 6 LX45, complaining "instruction capture is 0x3f". The JTAG chain itself was recognized, it reported the device correctly. The cause was insufficient 3.3 V supply voltage on the FPGA board, measured at around 3.08 V. Some modification to the LM1117 adjustment resistors brought it back up to 3.3 V and the board works again. Don't know if all variants of this regulator have overcurrent protection, maybe it was damaged by earlier abuse. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157005
>> (solved) or not. The problem re-appeared, probably the board is broken. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157006
mnentwig <24789@embeddedrelated> wrote: > >> (solved) > or not. > The problem re-appeared, probably the board is broken. Please let me know if the problem comes out as not hardware related. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 157007
Hey guys(and gals) FPGA convert here trying to use bidirectional pins on an Altera Board within a data acquisition project. What are the ways to implement such a design in VHDL or Verilog? Thanks! OluArticle: 157008
<osodipe@eng.ucsd.edu> wrote in message news:5f2f4946-2e38-4875-9e0e-e27c70128514@googlegroups.com... > Hey guys(and gals) > > FPGA convert here trying to use bidirectional pins on an Altera Board > within a data acquisition project. What are the ways to implement such a > design in VHDL or Verilog? Thanks! > > Olu Declare the pin as bidirectional. Drive the pin with a tristate driver. Ignore data coming in to the pin while the tristate is enabled. AndyArticle: 157009
On Monday, August 25, 2014 9:18:59 AM UTC-4, oso...@eng.ucsd.edu wrote: > Hey guys(and gals) FPGA convert here trying to use bidirectional pins on = an Altera Board within a data acquisition project. What are the ways to imp= lement such a design in VHDL or Verilog? Thanks! Olu Thanks, guys. I have actually been going the tri-state route with not much = success and I was hoping there was a different way to implement bidirection= al signals on an FPGA. To clarify further, my HDL simulates fine but my syn= thesis leaves much to be desired. I have disparate write and read cycles co= ntrolled by an FSM but for some reason, whatever I write into the ADC durin= g the write cycle is being "echoed back" to me during my read(to read ADC d= ata) cycle. Here is my current Verilog code inout [11:0] adc_data_pin_top, assign adc_data_pin_top =3D ~write_adc_data ? written_data_temp : 12'b= z; assign data_from_adc =3D converted_datas; always @ (posedge adc_clock) begin converted_datas <=3D adc_data_pin_top; written_data_temp <=3D written_data_adc; endArticle: 157010
On 8/25/2014 1:57 PM, osodipe@eng.ucsd.edu wrote: > On Monday, August 25, 2014 9:18:59 AM UTC-4, oso...@eng.ucsd.edu wrote: >> Hey guys(and gals) FPGA convert here trying to use bidirectional pins on an Altera Board within a data acquisition project. What are the ways to implement such a design in VHDL or Verilog? Thanks! Olu > > Thanks, guys. I have actually been going the tri-state route with not much success and I was hoping there was a different way to implement bidirectional signals on an FPGA. To clarify further, my HDL simulates fine but my synthesis leaves much to be desired. I have disparate write and read cycles controlled by an FSM but for some reason, whatever I write into the ADC during the write cycle is being "echoed back" to me during my read(to read ADC data) cycle. Here is my current Verilog code > > inout [11:0] adc_data_pin_top, > assign adc_data_pin_top = ~write_adc_data ? written_data_temp : 12'bz; > assign data_from_adc = converted_datas; > > always @ (posedge adc_clock) > begin > converted_datas <= adc_data_pin_top; > written_data_temp <= written_data_adc; > end What is controlling the signal write_adc_data? That signal should be low when writing data and high when reading. What is driving the signal written_data_adc? Do you really need to register it? Can you explain why the ADC bus needs to be written? Is there setup data that needs to be sent to it or are you talking to another device like a DAC? -- RickArticle: 157011
Hey Rick, Thanks for your response. The write_adc_data is a low enable signal generat= ed by a Finite State Machine and yes, it is low when writing and high the r= est of the time. My read requires an additional enable, though. You are pro= bably right about the need to register the separate input/output signals--t= he IO cell has an inbuilt register I was trying to use, but there is a line= that bypasses that(meaning I could probably get away with a continuous ass= ignment statement). How does the register/no register impact my design besi= des timing? On Monday, August 25, 2014 4:32:49 PM UTC-4, rickman wrote: > On 8/25/2014 1:57 PM, wrote: > On Monday, August 25, 2014 9:18:59 AM UTC= -4, wrote: >> Hey guys(and gals) FPGA convert here trying to use bidirectio= nal pins on an Altera Board within a data acquisition project. What are the= ways to implement such a design in VHDL or Verilog? Thanks! Olu > > Thanks= , guys. I have actually been going the tri-state route with not much succes= s and I was hoping there was a different way to implement bidirectional sig= nals on an FPGA. To clarify further, my HDL simulates fine but my synthesis= leaves much to be desired. I have disparate write and read cycles controll= ed by an FSM but for some reason, whatever I write into the ADC during the = write cycle is being "echoed back" to me during my read(to read ADC data) c= ycle. Here is my current Verilog code > > inout [11:0] adc_data_pin_top, > = assign adc_data_pin_top =3D ~write_adc_data ? written_data_temp : 12'bz; > = assign data_from_adc =3D converted_datas; > > always @ (posedge adc_clock) = > begin > converted_datas <=3D adc_data_pin_top; > written_data_temp <=3D w= ritten_data_adc; > end What is controlling the signal write_adc_data? That = signal should be low when writing data and high when reading. What is drivi= ng the signal written_data_adc? Do you really need to register it? Can you = explain why the ADC bus needs to be written? Is there setup data that needs= to be sent to it or are you talking to another device like a DAC? -- RickArticle: 157012
On Mon, 25 Aug 2014 10:57:47 -0700, osodipe wrote: > assign adc_data_pin_top = ~write_adc_data ? written_data_temp : 12'bz; And if you change this to 12'bzzzzzzzzzzzz ? I had problems of that sort once.Article: 157013
Before reading from a bidirectional pin, make sure you "release" the pin to tristate first. Similarly, wait for the peripheral (connected to your FPGA) to be ready to read your data, before driving the pin to any deterministic value ('0' or '1'). E.g.: entity bidir is port(adc_data_pin_top: inout std_ulogic_vector(11 downto 0)); end entity bidir; architecture rtl of bidir is signal write_adc_data: boolean; -- flag to enable writing. begin adc_data_pin_top <= written_data_temp when write_adc_data else (others=>'Z'); process(adc_clock) is begin if rising_edge(adc_clock) then converted_datas <= adc_data_pin_top when not write_adc_data; -- use if-else if your tool doesn't yet support this. written_data_temp <= written_data_adc; end if; end process; end architecture rtl; It's better to have both the write and read as synchronous clocked processes though. -danArticle: 157014
On Wednesday, 27 August 2014 04:05:38 UTC+8, Daniel Kho wrote: > adc_data_pin_top <= written_data_temp when write_adc_data else (others=>'Z'); > Here, the slave's readiness to read data from your FPGA may be used to determine the value of write_adc_data. > converted_datas <= adc_data_pin_top when not write_adc_data; -- use if-else if your tool doesn't yet support this. > Save the data only when the line has already been released to (others=>'Z') by the driver process, and the slave is sending data. You may add additional checks here.Article: 157015
In article <lti4vv$984$2@speranza.aioe.org>, Aleksandar Kuktin <akuktin@gmail.com> wrote: >On Mon, 25 Aug 2014 10:57:47 -0700, osodipe wrote: > >> assign adc_data_pin_top = ~write_adc_data ? written_data_temp : 12'bz; > >And if you change this to 12'bzzzzzzzzzzzz ? I had problems of that sort >once. This. I'm fairly certain that the code the OP originally wrote would assign adc_data_pin_top to 12'b0000_0000_000z when write_adc_data == 1. Instead of the desired all tri-state. Later versions of verilog (2001, or maybe it's systemverilog, I don't recall) had some kind of syntactic sugar that's interpreted as "z-extend" the top bits (instead of the default 0 fill). Instead of the long string of Z's I use the verilog replication operator i.e. assign adc_data_pin_top = ( ~write_adc_data ) ? written_data_temp : { 12 { 1'bz } }; Regards, MarkArticle: 157016
Hi Pedro, I am sorry i don't have solution for your problem, but can you please tell me how did you get Power Estimation Confidence High: user provided sufficient toggle rate data in your report, i always get Power Estimation Confidence Low: user provided insufficient toggle rate data in my report, can you tell me how do i provide sufficient toggle rate data. Thank You Kiran PrinceArticle: 157017
Has anyone experience the Vivado waveform viewer just making up waveforms? I have a module with two different signals, lets say x and y if I go down the hierarchy and add them to the waveform view they show up as identical and the waveform shown looks like an OR of the expected values. If I add the two signals as outputs to the module and connect them to wires a level up and add those two the waveform those waveforms are correct what's going on? -LasseArticle: 157018
Hi, I can't comment on that but maybe "gtkwave" is an interesting alternative. It's very popular. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157019
Hi, I wasn't able to find a bscan .bit file to program the flash on my Xula2 board so I built it myself. Link follows, includes also the .ucf file (only LOCs for the flash pins, nothing else). It requires an external JTAG interface and a Xula2 board needs to be configured for external JTAG (see manual). In other words, it will -not- work through the USB connector on the board. The vendor's tool will do that (but I didn't succeed in running it on Windows 8.1). Use at your own risk. https://drive.google.com/file/d/0B1gLUU8hXL7vakJyV2c4SXplRTQ/edit?usp=sharing --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157020
Hello, I wonder maybe someone have automotive functional safety guidelines for VHDL and is willing to share? I think there's a package available from Altera, however they charge 10k for it telling that it is a small fee. Thank you.Article: 157021
Am 01.09.2014 um 00:15 schrieb Tomas D.: > Hello, > I wonder maybe someone have automotive functional safety guidelines for VHDL > and is willing to share? > I think there's a package available from Altera, however they charge 10k for > it telling that it is a small fee. > > Thank you. > > Hi, maybe this one is something for you: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5712336&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5712336 It's not specially for automotive and not very informative, but maybe a first idea. Best regards, TobiasArticle: 157022
On 8/31/2014 3:15 PM, Tomas D. wrote: > Hello, > I wonder maybe someone have automotive functional safety guidelines for VHDL > and is willing to share? > I think there's a package available from Altera, however they charge 10k for > it telling that it is a small fee. > > Thank you. > It's not automotive - but the aerospace industry uses RTCA DO-254. http://en.wikipedia.org/wiki/DO-254 Rob.Article: 157023
On Tuesday, 19 January 2010 11:29:56 UTC, Roger wrote: > Due to a bug in the Easy PC software tool from Numberone Systems, I've ju= st=20 > had a very time consuming and costly incident.... I just sent off a last minute design to China with NO copper pour (deadline= s mean I just had to fatten tracks and try to ignore CE TCFs etc). Worked f= ine on earlier version of the board but .. no go on this one. Forums full o= f similar complaints, but no solution.=20 In addition, I must be one of their 1st customers, and over the years I've = spent way more than 1K on it, so Colin, don't go preaching the You get what= you Pay For line :-).=20 However, I am also a software developer and I have sympathy for No1. What w= ould be a good-will gesture that doesn't seriously hit their bottom line?= =20 The difficulty is getting paid without doing endless updates, and with endl= ess updates comes change, and .. it sure ain't "Easy" PC anymore. There mus= t be something easier out there. The Help on it does my head in (I can see = they've tried, but when you are sitting there thinking .. how do I do that?= Don't bother looking at help!).=20 Summary: They could do with a clear out. Copper Pour needs a re-write. The = rest needs simplifying, as after all it was never a tool for corporate need= s, but it was a good tool for serious professional with low volume requirem= ents. They have my continued support. Just.Article: 157024
On 03/09/2014 02:42, quarrie92@googlemail.com wrote: > On Tuesday, 19 January 2010 11:29:56 UTC, Roger 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.... > > I just sent off a last minute design to China with NO copper pour (deadlines mean I just had to fatten tracks and try to ignore CE TCFs etc). Worked fine on earlier version of the board but .. no go on this one. Forums full of similar complaints, but no solution. > > In addition, I must be one of their 1st customers, and over the years I've spent way more than 1K on it, so Colin, don't go preaching the You get what you Pay For line :-). > > However, I am also a software developer and I have sympathy for No1. What would be a good-will gesture that doesn't seriously hit their bottom line? > > The difficulty is getting paid without doing endless updates, and with endless updates comes change, and .. it sure ain't "Easy" PC anymore. There must be something easier out there. The Help on it does my head in (I can see they've tried, but when you are sitting there thinking .. how do I do that? Don't bother looking at help!). > > Summary: They could do with a clear out. Copper Pour needs a re-write. The rest needs simplifying, as after all it was never a tool for corporate needs, but it was a good tool for serious professional with low volume requirements. They have my continued support. Just. > Not quite sure why you are posting this as a response to a 4 year old post but I'm assuming that your comment is current. I'm a long term user of EasyPC and I don't agree with most of your comments at all. It still is a very simple and low cost tool. And although the copper pour still has issues the general reliability of the product is much better than the much more expensive PCB cad tools I've used. The Help, as with anything , could be better but it's not bad. (BTW - if you get stuck with a copper pour problem then reduce the pour area until you locate the offending item that it won't pour round - this will usually get you out of immediate trouble. And do tell No1 about the problem - they do fix stuff.) Michael Kellett
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