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
In article <orare6$vci$1@dont-email.me>, nospam@nospam.com says... > > No experience with that board, however I have had experience > with the Artix-7 35T. It's basically a 50T nobbled in software. > The way Xilinx does this leaves the entire 50T fabric available, > but limits the number of each fabric component you can use. This > results in a device that can easily work with a 100% "full" > design, since it's the equivalent of a 70% full 50T. Either > this device (smaller Artix-7 series) or Spartan-7 requires Vivado > software. ISE does not support them. > > From the description it looks like the board has very little > external RAM, both considering total storage capacity and > bandwidth. A single 8-bit wide DDR3 memory would have more > of both, at least for streaming data like video. In general > I use the peripherals of a board to help me decide if I can > use it more than the FPGA itself. If you're not interested > in video processing, it's probably OK. Hi Gabor Thanks for the info - yes I'm looking at them specifically because they work with Vivado. I don't need a lot of resources as their use will be to prototype cpu components (stacks, control paths etc) Once developed the components will be integrated on a much more capable system. As long as they have enough resources to do at least one cpu function comfortably they should do the job I need I think. There are no complex or high bandwidth full apps it has to run. Does all that seem reasonable? -- john ========================= http://johntech.co.uk =========================Article: 160276
Hi, I am working on UART receiver. As of now, I am stucked at http://paste.ubuntu.com/25720292/ I could not find a proper hardware writing style to continue with line 14
the overall hierarchy : https://i.imgur.com/lVEtKXT.png
module sampling_strobe_generator(clk, start_detected, sampling_strobe); // produces sampling signal for the incoming Rx
input clk, start_detected;
output reg sampling_strobe = 0;
localparam CLOCKS_PER_BIT = 5000; // number of system clock in one UART bit, or equivalently 1/9600Hz divided by 1/48MHz
reg [($clog2(CLOCKS_PER_BIT)-1) : 0] counter = 0;
always @(posedge clk)
begin
if(start_detected)
counter <= 0;
else
end
always @(posedge clk)
begin
counter <= counter + 1;
end
endmodule
module rx_state(clk, start_detected, sampling_strobe, data_is_available, data_is_valid, is_parity_stage); // FSM for UART Rx
input clk, start_detected, sampling_strobe;
output reg data_is_available = 0;
output reg data_is_valid = 0;
output reg is_parity_stage = 0;
reg [3:0] state = 0;
localparam Rx_IDLE = 4'b0000
localparam Rx_START_BIT = 4'b0001
localparam Rx_DATA_BIT_0 = 4'b0010
localparam Rx_DATA_BIT_1 = 4'b0011
localparam Rx_DATA_BIT_2 = 4'b0100
localparam Rx_DATA_BIT_3 = 4'b0101
localparam Rx_DATA_BIT_4 = 4'b0110
localparam Rx_DATA_BIT_5 = 4'b0111
localparam Rx_DATA_BIT_6 = 4'b1000
localparam Rx_DATA_BIT_7 = 4'b1001
localparam Rx_PARITY_BIT = 4'b1010
localparam Rx_STOP_BIT = 4'b1011
always @(posedge clk)
begin
data_is_valid <= (state == Rx_STOP_BIT); // so as to align with rx_error
is_parity_stage <= (state == Rx_PARITY_BIT); // parity state
data_is_available <= ((state >= Rx_DATA_BIT_0) && (state <= Rx_DATA_BIT_7)); // data states
end
always @(posedge clk)
begin
if (sampling_strobe) begin
case(state)
Rx_IDLE : state <= (start_detected) ? Rx_START_BIT : Rx_IDLE;
Rx_START_BIT : state <= Rx_DATA_BIT_0;
Rx_DATA_BIT_0,
Rx_DATA_BIT_1,
Rx_DATA_BIT_2,
Rx_DATA_BIT_3,
Rx_DATA_BIT_4,
Rx_DATA_BIT_5,
Rx_DATA_BIT_6,
Rx_DATA_BIT_7 : state <= state + 1'b1;
Rx_PARITY_BIT : state <= Rx_STOP_BIT;
Rx_STOP_BIT : state <= Rx_IDLE;
default : state <= Rx_IDLE;
endcase
end
end
endmodule
Article: 160277promach wrote on 10/11/2017 10:06 AM: > Hi, I am working on UART receiver. As of now, I am stucked at http://paste.ubuntu.com/25720292/ I could not find a proper hardware writing style to continue with line 14 > > the overall hierarchy : https://i.imgur.com/lVEtKXT.png > > > > > > module sampling_strobe_generator(clk, start_detected, sampling_strobe); // produces sampling signal for the incoming Rx > > input clk, start_detected; > output reg sampling_strobe = 0; > > localparam CLOCKS_PER_BIT = 5000; // number of system clock in one UART bit, or equivalently 1/9600Hz divided by 1/48MHz > > reg [($clog2(CLOCKS_PER_BIT)-1) : 0] counter = 0; > > always @(posedge clk) > begin > if(start_detected) > counter <= 0; > else > > end > > always @(posedge clk) > begin > counter <= counter + 1; > end > > endmodule > > > > module rx_state(clk, start_detected, sampling_strobe, data_is_available, data_is_valid, is_parity_stage); // FSM for UART Rx > > input clk, start_detected, sampling_strobe; > output reg data_is_available = 0; > output reg data_is_valid = 0; > output reg is_parity_stage = 0; > > reg [3:0] state = 0; > > localparam Rx_IDLE = 4'b0000 > localparam Rx_START_BIT = 4'b0001 > localparam Rx_DATA_BIT_0 = 4'b0010 > localparam Rx_DATA_BIT_1 = 4'b0011 > localparam Rx_DATA_BIT_2 = 4'b0100 > localparam Rx_DATA_BIT_3 = 4'b0101 > localparam Rx_DATA_BIT_4 = 4'b0110 > localparam Rx_DATA_BIT_5 = 4'b0111 > localparam Rx_DATA_BIT_6 = 4'b1000 > localparam Rx_DATA_BIT_7 = 4'b1001 > localparam Rx_PARITY_BIT = 4'b1010 > localparam Rx_STOP_BIT = 4'b1011 > > always @(posedge clk) > begin > data_is_valid <= (state == Rx_STOP_BIT); // so as to align with rx_error > is_parity_stage <= (state == Rx_PARITY_BIT); // parity state > data_is_available <= ((state >= Rx_DATA_BIT_0) && (state <= Rx_DATA_BIT_7)); // data states > end > > always @(posedge clk) > begin > if (sampling_strobe) begin > case(state) > Rx_IDLE : state <= (start_detected) ? Rx_START_BIT : Rx_IDLE; > > Rx_START_BIT : state <= Rx_DATA_BIT_0; > > Rx_DATA_BIT_0, > Rx_DATA_BIT_1, > Rx_DATA_BIT_2, > Rx_DATA_BIT_3, > Rx_DATA_BIT_4, > Rx_DATA_BIT_5, > Rx_DATA_BIT_6, > Rx_DATA_BIT_7 : state <= state + 1'b1; > > Rx_PARITY_BIT : state <= Rx_STOP_BIT; > > Rx_STOP_BIT : state <= Rx_IDLE; > > default : state <= Rx_IDLE; > endcase > end > end > > endmodule I believe the module sampling_strobe_generator is intended to provide a strobe aligned to the center of the bit. The question I have is what is the specification of the signal "start_detected"? Is that aligned to the center of the start bit? Where are you rejecting false start bits? -- Rick C Viewed the eclipse at Wintercrest Farms, on the centerline of totality since 1998Article: 160278
On Saturday, August 5, 2017 at 8:40:25 PM UTC+2, Edward Moore wrote: > suggestions for alternative fpga-related forums ? www.reddit.com/r/fpga -- SvennArticle: 160279
Dear All, I am a student with primitive experience in verilog. I have a small verific= ation task for a top module. I have simplified the task in the below descri= ption, so that you can give me a quick response. There could be solve for t= his problem in various ways. But ideally I am finding a solution to create = an automatic test setup. Please find below the problem. If you could write me a solution with a work= ing example in verilog, that would be a good starting point. Write a Script or Test bench for the following tasks; Send Data =3D 8 bits and Received Data is 16 bits. 1. First Send Data for 0-256 data frames with STATUS_IN =3D 0, and then aga= in Send Data 0-256 data frames with STATUS_IN =3D 1 2. Next send few control frames of 8 bits with specific pattern (e.g. 8'b00= 110101) again with STATUS_IN =3D 0 and STATUS_IN =3D 1 3. Compare if Send Data =3D=3D Received Data at the DATA_OUT port. Also com= pare if STATUS_IN =3D=3D STATUS_OUT for every received data frame 4. Print SUCCESS or FAIL for every data frame transmission in a File (use F= ile handling) File handling: Print Send Data and Received Data, Print STATUS_IN and STATU= S_OUT and SUCCESS and FAIL for each data frame transmission One additional task is to breaking 16 bits Received Data in two 8 bits for = each cycle. Find attached the diagram of the module.Article: 160280
Some hams want to work with FPGAs to generate high speed PN sequences in the GHz range. LFSR designs are about as simple as you can get in an FPGA. The only trick is getting the resulting signal out of the FPGA. Rather than outputting a parallel word at some 100's of MHz into a shift register clocked in the GHz range, it seems easier to use a SERDES to shift it out directly from the FPGA. But not all FPGAs have SERDES. Which are the lowest cost devices and the easiest to use? By "easiest" I mean board level with a built in programming interface so they just connect a USB cable and maybe power supply, no dongle needed. All the FPGAs I've worked with lately (by that I mean over the last 10 years) didn't include a SERDES. -- Rick C Viewed the eclipse at Wintercrest Farms, on the centerline of totality since 1998Article: 160281
rickman <gnuarm@gmail.com> wrote: > But not all FPGAs have SERDES. Which are the lowest cost devices and the > easiest to use? By "easiest" I mean board level with a built in > programming interface so they just connect a USB cable and maybe power > supply, no dongle needed. In Intel-land, the Cyclone IV GX and Cyclone V GX are the cheap transceiver devices - or the SX version if you also want an ARM core. There are boards like: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=139&No=746 http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=830 and with an ARM: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=816 I think the Lattice ECP5 also has transceiver support, though I haven't used it. For instance: http://www.latticesemi.com/Products/FPGAandCPLD/ECP5ECP5GPromotion.aspx (one thing to watch is any additional licences that may be needed) The other question is: what do you want to connect it to? It's a GHz frequency signal, so you'll need to take care of signal integrity to get it anywhere. Therefore the connector format you intend to use may be important. TheoArticle: 160282
Theo Markettos wrote on 10/21/2017 3:19 PM: > rickman <gnuarm@gmail.com> wrote: >> But not all FPGAs have SERDES. Which are the lowest cost devices and the >> easiest to use? By "easiest" I mean board level with a built in >> programming interface so they just connect a USB cable and maybe power >> supply, no dongle needed. > > In Intel-land, the Cyclone IV GX and Cyclone V GX are the cheap transceiver > devices - or the SX version if you also want an ARM core. > > There are boards like: > http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=139&No=746 > http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=830 > and with an ARM: > http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=816 > > I think the Lattice ECP5 also has transceiver support, though I haven't used > it. For instance: > http://www.latticesemi.com/Products/FPGAandCPLD/ECP5ECP5GPromotion.aspx > > (one thing to watch is any additional licences that may be needed) > > The other question is: what do you want to connect it to? > It's a GHz frequency signal, so you'll need to take care of signal integrity > to get it anywhere. Therefore the connector format you intend to use may be > important. The ham is using it as an analog signal, so he won't be caring about harmonics. It is a noise source for test gear, uniform over a wide bandwidth. I assume a ham can handle the analog aspects of the signal, lol. Too bad that promo on the ECP5 board expired. I dug around a little and didn't find a SERDES on any of the Flash based parts by Lattice. I don't see any Altera boards with SERDES under $100. I guess if they are using the chip with the SERDES they figure you are going to use it with PCIe or similar, so the cost goes up. -- Rick C Viewed the eclipse at Wintercrest Farms, on the centerline of totality since 1998Article: 160283
Theo Markettos wrote on 10/21/2017 3:19 PM: > rickman <gnuarm@gmail.com> wrote: >> But not all FPGAs have SERDES. Which are the lowest cost devices and the >> easiest to use? By "easiest" I mean board level with a built in >> programming interface so they just connect a USB cable and maybe power >> supply, no dongle needed. > > In Intel-land, the Cyclone IV GX and Cyclone V GX are the cheap transceiver > devices - or the SX version if you also want an ARM core. > > There are boards like: > http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=139&No=746 > http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=830 > and with an ARM: > http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=816 > > I think the Lattice ECP5 also has transceiver support, though I haven't used > it. For instance: > http://www.latticesemi.com/Products/FPGAandCPLD/ECP5ECP5GPromotion.aspx > > (one thing to watch is any additional licences that may be needed) > > The other question is: what do you want to connect it to? > It's a GHz frequency signal, so you'll need to take care of signal integrity > to get it anywhere. Therefore the connector format you intend to use may be > important. While trying to dig through the Altera/Intel datasheets it seems they don't have the same sort of documents they used to have. Everything is broken up into many smaller manuals and most don't even have lead in information like a table of contents or intro page, it just starts with data! Is this an Intel thing? -- Rick C Viewed the eclipse at Wintercrest Farms, on the centerline of totality since 1998Article: 160284
rickman <gnuarm@gmail.com> wrote: > While trying to dig through the Altera/Intel datasheets it seems they don't > have the same sort of documents they used to have. Everything is broken up > into many smaller manuals and most don't even have lead in information like > a table of contents or intro page, it just starts with data! Is this an > Intel thing? No, the Altera site is pretty much the same as before the rebrand. They do two versions of documentation: one is the whole manual for the chip, sometimes split into a couple of volumes (eg vol1 internals, vol2 transceivers). Then the individual chapters are also available separately. When googling, the individual bits tend to rank higher - but when you want the whole document to read it's useful to know you can go to the device page and get the full PDF. Also worth bearing in mind there's lots of sharing - lots of features are the same across families, so no point duplicating info. My point about connectors is that often transceivers come off on FMC or HSMC connectors - can your ham deal with those? You'll need a PCB, probably a 4 layer one if you're going more than a few mm. TheoArticle: 160285
Theo Markettos wrote on 10/21/2017 6:24 PM: > rickman <gnuarm@gmail.com> wrote: >> While trying to dig through the Altera/Intel datasheets it seems they don't >> have the same sort of documents they used to have. Everything is broken up >> into many smaller manuals and most don't even have lead in information like >> a table of contents or intro page, it just starts with data! Is this an >> Intel thing? > > No, the Altera site is pretty much the same as before the rebrand. > They do two versions of documentation: one is the whole manual for the chip, > sometimes split into a couple of volumes (eg vol1 internals, vol2 > transceivers). Then the individual chapters are also available separately. > When googling, the individual bits tend to rank higher - but when you want > the whole document to read it's useful to know you can go to the device page > and get the full PDF. Also worth bearing in mind there's lots of sharing - > lots of features are the same across families, so no point duplicating info. I wasn't able to find the usual info that is easily available on other makers' sites. They typically have a basic family manual that starts with the overview and a summary of the devices in the family and the available packages. This is followed by a high level description of the various aspects of the workings of the chip and finally electrical and mechanical data. Usually the fine points are covered in other manuals or tech notes. When I typed in "cyclone V datasheet" I got some hundreds of hits ranked by I assume relevance. Electrical specs came up first. I never found what I was looking for. I had to rely on the brief info on the web pages. > My point about connectors is that often transceivers come off on FMC or HSMC > connectors - can your ham deal with those? You'll need a PCB, probably a 4 > layer one if you're going more than a few mm. Yeah, the guy seems to be thinking of putting a 20 pin device on his own circuit board. I found a $30 Lattice FPGA board without SERDES for him, and they also have some parts in QFN and there's always the ever present 144 pin QFP. But he is talking about using ECL now. Whatever. Horse - water... -- Rick C Viewed the eclipse at Wintercrest Farms, on the centerline of totality since 1998Article: 160286
rickman <gnuarm@gmail.com> wrote: > I wasn't able to find the usual info that is easily available on other > makers' sites. They typically have a basic family manual that starts with > the overview and a summary of the devices in the family and the available > packages. This is followed by a high level description of the various > aspects of the workings of the chip and finally electrical and mechanical > data. Usually the fine points are covered in other manuals or tech notes. > When I typed in "cyclone V datasheet" I got some hundreds of hits ranked by > I assume relevance. Electrical specs came up first. I never found what I > was looking for. I had to rely on the brief info on the web pages. The starting point for Cyclone V docs is here: https://www.altera.com/products/fpga/cyclone-series/cyclone-v/support.html That seems to have what you suggest, just split over several manuals. > Yeah, the guy seems to be thinking of putting a 20 pin device on his own > circuit board. I found a $30 Lattice FPGA board without SERDES for him, > and they also have some parts in QFN and there's always the ever present > 144 pin QFP. But he is talking about using ECL now. Whatever. Horse - > water... I haven't seen a device with transceivers that wasn't a BGA, so you might be in for trouble... One option beyond the dev board is systems-on-module, where the FPGA is on a carrier board and all signals are pinned out to connectors. That converts the problem into interfacing with an FMC or similar connector. It isn't impossible to do that with careful design on a 2 layer PCB (and the cheap devices are max 3Gbps which isn't that fast), but do understand it won't be a case of just plugging in. TheoArticle: 160287
On 22.10.2017 0:04, rickman wrote: > Theo Markettos wrote on 10/21/2017 3:19 PM: >> rickman <gnuarm@gmail.com> wrote: >>> But not all FPGAs have SERDES. Which are the lowest cost devices and >>> the >>> easiest to use? By "easiest" I mean board level with a built in >>> programming interface so they just connect a USB cable and maybe power >>> supply, no dongle needed. >> >> In Intel-land, the Cyclone IV GX and Cyclone V GX are the cheap >> transceiver >> devices - or the SX version if you also want an ARM core. >> >> There are boards like: >> http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=139&No=746 >> >> http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=830 >> >> and with an ARM: >> http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=816 >> >> >> I think the Lattice ECP5 also has transceiver support, though I >> haven't used >> it. For instance: >> http://www.latticesemi.com/Products/FPGAandCPLD/ECP5ECP5GPromotion.aspx >> >> (one thing to watch is any additional licences that may be needed) >> >> The other question is: what do you want to connect it to? >> It's a GHz frequency signal, so you'll need to take care of signal >> integrity >> to get it anywhere. Therefore the connector format you intend to use >> may be >> important. > > The ham is using it as an analog signal, so he won't be caring about > harmonics. It is a noise source for test gear, uniform over a wide > bandwidth. I assume a ham can handle the analog aspects of the signal, > lol. > Besides, it's an interesting type of a DSP problem. A case for which an m-sequence transform at the receiver side is an efficient solution. GeneArticle: 160288
Evgeny Filatov wrote on 10/22/2017 6:02 AM: > > Besides, it's an interesting type of a DSP problem. A case for which an > m-sequence transform at the receiver side is an efficient solution. I'm not sure what you are describing. I remember learning about a photoacoustic spectrometer my professor was working on. It used a disk with slots to shutter the optical beam from a monochromator and self interfered by the disk making noise and vibrations. I wondered if that could be mitigated by making the slots in the disk different widths and detecting the acoustic signal in a synchronized manner. I wasn't schooled in electronics yet and didn't realize that is the basis of DSP techniques. Is that the sort of thing you are talking about? -- Rick C Viewed the eclipse at Wintercrest Farms, on the centerline of totality since 1998Article: 160289
Theo Markettos wrote on 10/22/2017 5:55 AM: > rickman <gnuarm@gmail.com> wrote: >> I wasn't able to find the usual info that is easily available on other >> makers' sites. They typically have a basic family manual that starts with >> the overview and a summary of the devices in the family and the available >> packages. This is followed by a high level description of the various >> aspects of the workings of the chip and finally electrical and mechanical >> data. Usually the fine points are covered in other manuals or tech notes. >> When I typed in "cyclone V datasheet" I got some hundreds of hits ranked by >> I assume relevance. Electrical specs came up first. I never found what I >> was looking for. I had to rely on the brief info on the web pages. > > The starting point for Cyclone V docs is here: > https://www.altera.com/products/fpga/cyclone-series/cyclone-v/support.html > That seems to have what you suggest, just split over several manuals. > >> Yeah, the guy seems to be thinking of putting a 20 pin device on his own >> circuit board. I found a $30 Lattice FPGA board without SERDES for him, >> and they also have some parts in QFN and there's always the ever present >> 144 pin QFP. But he is talking about using ECL now. Whatever. Horse - >> water... > > I haven't seen a device with transceivers that wasn't a BGA, so you might be > in for trouble... > > One option beyond the dev board is systems-on-module, where the FPGA is on a > carrier board and all signals are pinned out to connectors. That converts > the problem into interfacing with an FMC or similar connector. It isn't > impossible to do that with careful design on a 2 layer PCB (and the cheap > devices are max 3Gbps which isn't that fast), but do understand it won't be > a case of just plugging in. I don't believe he was serious about using an FPGA. He seems to be just talking about things and not so interested in anything that he can't build himself. -- Rick C Viewed the eclipse at Wintercrest Farms, on the centerline of totality since 1998Article: 160290
On 23.10.2017 2:00, rickman wrote: > Evgeny Filatov wrote on 10/22/2017 6:02 AM: >> >> Besides, it's an interesting type of a DSP problem. A case for which an >> m-sequence transform at the receiver side is an efficient solution. > > I'm not sure what you are describing. > > I remember learning about a photoacoustic spectrometer my professor was > working on. It used a disk with slots to shutter the optical beam from > a monochromator and self interfered by the disk making noise and > vibrations. I wondered if that could be mitigated by making the slots in > the disk different widths and detecting the acoustic signal in a > synchronized manner. I wasn't schooled in electronics yet and didn't > realize that is the basis of DSP techniques. > > Is that the sort of thing you are talking about? > Not really. The type of setup you described can be used to measure impulse response of a system: http://www.commsp.ee.ic.ac.uk/~mrt102/projects/mls/MLS%20Theory.pdf Perhaps it's not what the ham is trying to achieve. Thought it's worth mentioning, though. GeneArticle: 160291
Hello, I have design my custom board using altera cylcone v (5CSEBA2U19I7S) with the reference of Cyclone V development board. When I am trying to debug the HPS using Embedded DS - 5 it shows me the error of local host. please help me to resolve this issue. Thanks, Krunal GandhiArticle: 160292
gkrunal72@gmail.com wrote: > Hello, > > I have design my custom board using altera cylcone v (5CSEBA2U19I7S) with > the reference of Cyclone V development board. > > When I am trying to debug the HPS using Embedded DS - 5 it shows me the > error of local host. Standard advice when asking for help: What is the exact error message you receive? Write it down. A screenshot or similar would also be useful. Theo (who has used DS5 on the HPS briefly, but no insight into what the error might be. 'Can't talk to the HPS' is my best guess - maybe the clocks or I/O pins are not set up correctly on the FPGA so it isn't communicating)Article: 160293
does anyone have a set of symbols that can help with fpga documentation? (Something for dia perhaps or coreldraw maybe) preferably not visio Or does everyone do this manually all the time? Clearly it's not that complex but what do you all use? -- john ========================= http://johntech.co.uk =========================Article: 160294
On 26/10/17 12:59, john wrote: > > does anyone have a set of symbols that can help with fpga documentation? > (Something for dia perhaps or coreldraw maybe) > preferably not visio > > Or does everyone do this manually all the time? > Clearly it's not that complex but what do you all use? > For drawing I use inkscape. It is quite easy to draw some symbols and reuse them everywhere. PereArticle: 160295
On Tuesday, September 9, 2008 at 2:53:51 AM UTC+5:30, m m wrote: > Thank you Sir. I checked on the oscilloscope and now it is working as > expected. > I was missing that signal (dac_clr). Also, I was declaring the '12-bit > unsigned data' of the 'frame' as 'std_logic_vector' instead of > 'unsigned'. >=20 >=20 > Thank you again, > m m > ____________________________ >=20 > On Aug 23, 6:47=C2=A0pm, Frank Buss <f...@frank-buss.de> wrote: > > > > I have implemented a simple test for the Spartan 3E starter kit board, > > which has the same DAC: > > > > http://www.frank-buss.de/SignalGenerator/ > > > > -- > > Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-s= ystems.deArticle: 160296
sir,please share the code which you got for interfacing fpga with DAC LTC2624Article: 160297
On 03.11.2017 19:28, sainath295@gmail.com wrote: > sir,please share the code which you got for interfacing fpga with DAC LTC2624 > Do you realize the message you're answering to was posted a bit more than 9 years ago ? NicolasArticle: 160298
Hi all, I'm making a system on iCE40 and I've ran out of PLLs. The design incorporates two DDR2 controllers that need to perform several operations delayed with respect to the system clock. I'm gonna use a phase delayed clock for that. So my approach is to take the clock signal and pipe it through several LUTs, thus delaying it. But - how comparable are LUT delays between different chips? As in, different pieces of FPGA silicon? If I implement this design, will every chip be a special snowflake that needs to be calibrated separately and use different lengths of LUT delay gates?Article: 160299
Aleksandar Kuktin wrote on 11/5/2017 3:38 PM: > Hi all, > > I'm making a system on iCE40 and I've ran out of PLLs. The design > incorporates two DDR2 controllers that need to perform several operations > delayed with respect to the system clock. I'm gonna use a phase delayed > clock for that. > > So my approach is to take the clock signal and pipe it through several > LUTs, thus delaying it. > > But - how comparable are LUT delays between different chips? As in, > different pieces of FPGA silicon? If I implement this design, will every > chip be a special snowflake that needs to be calibrated separately and > use different lengths of LUT delay gates? It can be done, but dependant on how accurate you need the delay to be. If you can live with variation over chips, temperature and power supply voltage of perhaps 50 % (a number scientifically pulled from air), it will work. If you are just trying to create some delay so data is stable when clock arrives or something like that were you have a lot of tolerance this can work. If you need precision (depending on your value of precision) it won't. There is also the issue of routing delays varying from one layout to another. My boss at one job had delayed a clock by manually routing the signal through a mux near the IOB. Then he didn't document how he made it work, lol. We needed to make a change to the design and he had to show us how he made it work including how he used the manual routing tool. Even then it was not documented by anyone. What a loose cannon! As is typically done when people ask "how long is a piece of string", what are you doing exactly? Maybe there is a better approach? -- Rick C Viewed the eclipse at Wintercrest Farms, on the centerline of totality since 1998
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