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
Test01 wrote: > I am using spartan3 fpga with lvcmos33 output pin set to 16 mA drive strength and fast slew rate. I am assuming that 16 mA is the source current at 3.3V as my VCCO voltage is 3.3V. I would like to know what is the sink current capability for LVCMOS33 OUTPUT pin is. Or is there any way I can increase the sink current capability? > > I am using this output pin as open drain type with 150 Ohm pulllup to 1.8V Plane. With this I am seeing low swing of 400mV. If the sink current was truely 16 mA, then the low swing should have been 0v. I raised the pullup value to 330 Ohms and the low swing was 200mV. > > In my opinion the 16 mA is source current capability. I need to make the output go down to 0v. > > Any help will be great. CMOS drive, Sink current is not a pure current source, it is spec'd at some Vol level, and for a given PinDrive selection it will sink MORE than that level. Real CMOS drivers are MOSFETS that look resistors, in the sub-volt saturation region. In your example, the 400mV is the expected drop across that resistor, and that is why it drops to 200mV when you halve the load current, by 150 => 330 Ohms. What is this driving ? - 400mV maybe fine as a Vol, or you could go to a higher Drive option and lower that 400mV. -jgArticle: 119576
Hi All, I have developed a design which obtained max freq. 56Mhz. So i applied global clock constraint to implement design and timimg is met. This design has sub-modules which are running above 100Mhz. my requirement is run this design at 90Mhz. when i applied global clock constraint for 90Mhz, then timing is not met. Finally i downloaded this design on board and see that design is working at 90Mhz. My question why tool is not meeting timing but design is working at board. I am not included false and multi-cycle path in design constraint file .Article: 119577
Hi , I am using Altera Quartus II version 4.0 . The EPS125 device has 138 M4K blocks 224 M512 blocks 2 number of 512K Mram blocks has a total of 1,944,576 bits. (http://www.altera.com/products/devices/stratix/features/stx- trimatrix.html ) the problem i am facing is i am trying to fit in 4 buffer data blocks each of size 16384*14 bits (total 229376*4 =917504) plus i have additional fifo and single port Ram of sizes 8192 , and 1500 bits The problem is though there is adequate RAM available , I am not able to fit in all the memory; only 48% of the RAM is used. The fitter resourse summary says more M-Ram blocks are required but most of M4K and M512 blokcs are not used. ie 40/224 M512 blocks are used, 2/138 M4K blocks and 2-MRam blocks... I am fairly new to FPGAs and stuff so i would appreciate all help. thanks and regards.Article: 119578
You asked the same question 2 days ago, and you got 9 replies. Why do you start again? Peter Alfke On May 22, 10:05 pm, "J.Ram" <jrgod...@gmail.com> wrote: > Hi All, > I have developed a design which obtained max freq. 56Mhz. So i applied > global clock constraint > to implement design and timimg is met. > This design has sub-modules which are running above 100Mhz. > my requirement is run this design at 90Mhz. > when i applied global clock constraint for 90Mhz, then timing is not > met. > Finally i downloaded this design on board and see that design is > working at 90Mhz. > My question why tool is not meeting timing but design is working at > board. > I am not included false and multi-cycle path in design constraint > file .Article: 119579
On 6 Apr., 21:04, Markus Knauss <markus.kna...@gmx.net> wrote: > Jon Elson wrote: > > > Markus Knauss wrote: > > >> Hi all, > > >> at the moment, we are using AT17LV010 configuration devices for a > >> spartan 2S100. > >> I have to look for a different solution which is not so expensive. > > >> The Xilinx XC17V01 is OTP and more expensive than the AT17LV010. > > >> Does someone know a different prom (OTP, EEPROM, Flash)? > > > SST makes a series of VERY cheap serial flash memories. I figured out > > how to > > create the command bit stream that it needs to command a read starting > > from addr > > zero function, using just 2 SSI CMOS chips in SSOP packages, so the > > interface is > > under $1, and the SST chip is well under $2 in small quantities. I had > > to make my > > own programmer, and a little C program to read the .MCS file and program > > the > > device. I haven't actually produced a product using this setup yet, but > > I did build > > a prototype board for Spartan 2E and verify that it could do the FPGA > > configure. > > I did this for the 2S50E part, but SST has up to 4 mbit chips, I think, > > that should > > handle the 2S100. > > > Jon > > Thank you Jon for the hint. It should be possible to get a preprogrammed > 8 bit controller (PIC, AVR) for 1$ and with a little bit banging in > software you could use the original .mcs file. > > Markus- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - you can get dev-kit for such microcontroller for 5 USD ;) http://www.dev-kit.org and yes there are plenty of sub 1USD microcontroller that can use as SPI to xilinx master serial adapter mcu holds FPGA in de-config (prog_b low), and clocks in the read instruction into SPI flash, then FPGA released and it will configure at programmed into bitstream clock rate from the SPI flash AnttiArticle: 119580
On 22 Mai, 22:03, Matthew Hicks <mdhic...@uiuc.edu> wrote: > Yes, there is documentation on the Xilinx site about how to do it and also > many previous posts on this very newsgroup about it. Think BSCAN. > > ---Matthew Hicks http://code.google.com/p/fpga-tools/downloads/list and there is VHDL source code of the BSCAN primitive as well AnttiArticle: 119581
or you just take any next sized primitive (or 2 in parallel) and pad the rest with zeros.Article: 119582
On 22 May, 13:41, sudhakar...@gmail.com wrote: > On May 22, 2:00 pm, francescopoder...@googlemail.com wrote: > > > > > On 22 May, 03:49, Digital Mike <michaelmk...@gmail.com> wrote: > > > > Dear all, > > > > I am working on a DDR controller that stores captured video frames > > > from which a VGA controller retrieves data. It (DDR controller) works > > > fine for the first few frames but seems dead afterward. I wonder if > > > anyone experienced similar problem. What I did (for initial testing > > > purpose) is to capture and store a frame into the DDR then retrieve > > > the same frame (a 640x480 pixels area) over and over again. > > > > Comments? > > > > -M > > > Hi Mike, > > I've got some experience with DDR2 controller. > > If you send me your code I can have a look. > > > Francesco > > Hi > Francesco > I am currently working on DDR2 controller for BL 8. > My own code is giving good results when i verified with memory model > from MICRON. > Now my problem is memory on the board is not sending 4 DQS clock > pulses. it seems to be sending for burst lenth 4. > > For ur IDEA some results i observed > > If i won't Initialize properly it is not responding at all . no > DQS nothing is comming . > if i initialize it properly its giving DQS signal of two sine clock > pulses. > If i write with 101010101 .... of each location i am getting two sine > clock pulses on DQ pin while reading . > if i write with all ZERO's i am getting ZERO' on DQ pin. > > so i think inialization is happenig properly. some problem persistence > still some where . > If u have any IDEA please help me regarding this. > with regards...... > sudhakar Hi sudhakar, What kind of FPGA wre you using? On the samsung website you can download some ddr2 memory model to verify that the initialization is ok. I don't have enought informations from you to help you. Last time I used MIG 7.1 succesfully . So if you are using a Xilinx FPGA I can reccomend you to use the MIG. FrancescoArticle: 119583
Thank you all very much, that's really helpful! ChrisArticle: 119584
On 22 Mai, 18:21, NewToFPGA <het...@yahoo.com> wrote: > Does Operating System need to provide an FPGA a device driver? Let me ask back: Does a graphics card require a device driver? No, it does not. It's the operating system that requires a devices driver to provide abstracted graphics card features to other programs. It's the same for FPGAs. If you want to provide FPGA based services to user space programs you need a device driver in most operating systems. In other operating systems you just read or write memory mapped registers directly from user space. If the FPGA is operating stand alone or is only used in kernel space there is no device driver required. Kolja SulimmaArticle: 119585
"Frai" <maybetooparanoid@gmail.com> wrote in message news:1179853461.318175.38170@36g2000prm.googlegroups.com... > I'm using a clock with 10 ns period. The delay of the path between > "locked_a_reg" and the synchronous reset of some FFs happens to be > very close to 10 ns. Therefore, the clock signal from the DCM > "dsp_clk_a" arrives at the FF almost at the same time as the reset > signal is released, throwing a SETUP violation in Modelsim. In the > real world, the FFs would just recover from this, but Modelsim doesn't > seem to handle this, and it stays with many unknown values at FFs that > prevent me from simulating my design. > > I've done quite much research on this topic with no success. I would > appreciate any information about why Xilinx doesn't detect such a > violation. > Hi Frai, So, here are some more questions. Apologies if they sound obvious, I'm unsure of your experience with the (often painful) world of FPGA design! :-) 1) Are you doing a timing simulation after place and route? I assume you are, otherwise you wouldn't have delays in your simulation! 2) Have you told the Xilinx software the period of the clock in your UCF file? The software can only detect timing errors if it knows the frequency of the clock. 3) Have you used the Xilinx timing analyser tool? As I said in my previous post, this will tell you what paths the P&R software is checking. 4) Also, is the clock buffered with a BUFG or somesuch onto a global clock net? If not, hang your head in shame! The skew on a clock routed in the general routing resource will make meeting timing a nightmare. I'm surprised that the net has delays of 10ns. That's quite a long time in today's parts. (You can try duplicating the FF that generates the reset to reduce this delay, but that doesn't address your question as to why the tools don't report timing errors.) HTH, Syms.Article: 119586
"John_H" <newsgroup@johnhandwork.com> wrote in message news:gUB4i.4817$ns.251@trndny05... > What a pretty list.... > > What device is this for? > I suggested going to the data sheet to see what inputs can be powered by > alternate VCCIOs. I can't go to the data sheet for you without knowing > which device - at least which family - you're using. > A google of IO_L74P_4/GCLK2P site:xilinx.com would suggest 2vp7ff672 HTH, Syms. > > LilacSkin wrote: >> That's my BANK 4: >> IO_L67P_4 BIDIR LVTTL >> IO_L05_4/No_Pair INPUT LVTTL >> IO_L07P_4/VREF_4 OUTPUT LVTTL >> IO_L19P_4 OUTPUT LVTTLArticle: 119587
On Tue, 22 May 2007 19:07:41 +0200, "L. Schreiber" <l.s.rockfan@web.de> wrote: >Brian Drummond schrieb: >> On Tue, 15 May 2007 19:00:05 +0200, "L. Schreiber" <l.s.rockfan@web.de> >> wrote: >> > >okay, this doesn't seem to work for the repos modules inside the >EDK/hw/XilinxProcessorIPLib/pcores. The error occoures before implement >design state (translate) in synthesize stage (syntax checking). > >XST tells me ERROR: HDLParsers:3317 - file_name.vhd Line xx. Library >lib_name cannot be found. For example library proc_sys_reset_v1_00_a. > >I think answer record #14027 says, I should add every missing library >(from EDK-directory) manually into my ISE project. I 've already tried >this. It has worked quite good until I tried to add a source file from >another library, which had the same name as one module included before. > >I got stuck again. > >Any advice? For me, XST simply black-boxed the EDK components below the top-level "system.vhd" file and the PAR tools picked them up later. I don't recall using "black-box" attributes; XST simply left them un-instantiated. However I think what you are doing SHOULD work. Except... it sounds like you have another problem : XST's handling of libraries seems to be consistently broken (at least on 6.1 and 7.1; I haven't tried newer versions). And this is completely independent of EDK; it seems to do this with any libraries. Which ISE version are you using? It is perfectly valid in VHDL to have the same entity name in several different libraries, and select a particular one for instantiation in any place with "library/use" clauses, and embedded configuration statements "for ... use " etc. But ISE simply instantiates the first component it finds with the right name and ignores your explicit bindings (in my experience). Now I ought to have spent a day or so creating a test case, reproducing the error with the test case, packaging the lot up and opening a Webcase with Xilinx, but I was under time pressure and it was quicker for me to simply rename one of the entities and carry on working. My experience with Webcases is typically, several iterations with the support staff, ending up with "Yes it's a bug". Sometimes with a scheduled fix in the next major release. And a recommendation to use the workaround I came up with in the first place. - BrianArticle: 119588
On May 23, 7:25 am, "Symon" <symon_bre...@hotmail.com> wrote: > "John_H" <newsgr...@johnhandwork.com> wrote in message > > news:gUB4i.4817$ns.251@trndny05...> What a pretty list.... > > > What device is this for? > > I suggested going to the data sheet to see what inputs can be powered by > > alternate VCCIOs. I can't go to the data sheet for you without knowing > > which device - at least which family - you're using. > > A google of IO_L74P_4/GCLK2P site:xilinx.com would suggest > 2vp7ff672 HTH, Syms. > > > > > LilacSkin wrote: > >> That's my BANK 4: > >> IO_L67P_4 BIDIR LVTTL > >> IO_L05_4/No_Pair INPUT LVTTL > >> IO_L07P_4/VREF_4 OUTPUT LVTTL > >> IO_L19P_4 OUTPUT LVTTL A look at Table 8 in the Virtex II Pro datasheet (Supported Single-ended I/O Standards) shows that LVCMOS25 requires 2.5V Vcco for input as well as output. This is confirmed in Table 12 (Summary of Voltage Supply Requirements for All Input and Output Standards). That being said, it is possible to drive an LVTTL input from an LVCMOS25 source. The important point is to check Voh (min) of the driving part and make sure it exceeds Vih (min) for the LVTTL input standard (2.0V per the datasheet). The other approach when using inputs that are not compatible with the Vcco reference is to use a standard like SSTL that uses the Vref to determine the logic threshold. In your case, since the Vref pins are already assigned to I/O, you don't have that option. HTH, GaborArticle: 119589
As per my understanding, you are suggesting an external transistor in parallel with the n-channel transistor to ground. The external transistor will turn on when the FPGA is driving low and will provide low resistance path to ground. Also you are suggesitng to raise the sink current value to 24 mA. Currently I am using 16 mA driver. I am assuming that 24 mA sink current will some how lower the resistance of the n-channel mosfet in the FPGA when it is on and help reduce the voltage drop across it. It will be great if you can expand on this. I am assuming that this solution will not require any external transistor to ground. Thanks for your feedback.Article: 119590
Hi guys,
To know how the synthesizer behave,i wrote logic to add 4
vectors in three different ways.And i got differnet result from the
synthesizer(used both ISE and synplify).
These are the three different approchs i made
1.***************************************************************************************************
module add(
input clk,
input [1:0] a,b,
input d,
input [63:0] c,
output reg [64:0] out
);
reg [1:0] in1,in2;
reg in4;
reg [63:0] in3;
wire [64:0] result;
always @ (posedge clk) begin
{in1,in2,in3,in4}= {a,b,c,d};
out= result;
end
assign result= in1+in2+in3+in4;
endmodule
2.***************************************************************************************************
module add1(
input clk,
input [1:0] a,b,
input d,
input [63:0] c,
output reg [64:0] out
);
reg [1:0] in1,in2;
reg in4;
reg [63:0] in3;
wire [64:0] temp;
wire [64:0] temp2;
wire [64:0] result;
always @ (posedge clk) begin
{in1,in2,in3,in4}= {a,b,c,d};
out= result;
end
assign temp= in1+in2;
assign temp2= temp+in4;
assign result= temp2+in3;
endmodule
3.***************************************************************************************************
module add2(
input clk,
input d,
input [1:0] a,b,
input [63:0] c,
output reg [64:0] out
);
reg [1:0] in1,in2;
reg in4;
reg [63:0] in3;
reg [64:0] result;
always @ (posedge clk) begin
{in1,in2,in3,in4}= {a,b,c,d};
out= result;
end
always @ (*) begin
case({in4,in1,in2})
5'b00000: result= in3+3'b000;
5'b00001: result= in3+3'b001;
5'b00010: result= in3+3'b010;
5'b00011: result= in3+3'b011;
5'b00100: result= in3+3'b001;
5'b00101: result= in3+3'b010;
5'b00110: result= in3+3'b011;
5'b00111: result= in3+3'b100;
5'b01000: result= in3+3'b010;
5'b01001: result= in3+3'b011;
5'b01010: result= in3+3'b100;
5'b01011: result= in3+3'b101;
5'b01100: result= in3+3'b011;
5'b01101: result= in3+3'b100;
5'b01110: result= in3+3'b101;
5'b01111: result= in3+3'b110;
5'b10000: result= in3+3'b001;
5'b10001: result= in3+3'b010;
5'b10010: result= in3+3'b011;
5'b10011: result= in3+3'b100;
5'b10100: result= in3+3'b010;
5'b10101: result= in3+3'b011;
5'b10110: result= in3+3'b100;
5'b10111: result= in3+3'b101;
5'b11000: result= in3+3'b011;
5'b11001: result= in3+3'b100;
5'b11010: result= in3+3'b101;
5'b11011: result= in3+3'b110;
5'b11100: result= in3+3'b100;
5'b11101: result= in3+3'b101;
5'b11110: result= in3+3'b110;
5'b11111: result= in3+3'b111;
endcase
end
endmodule
And the results for these from the ISE are
1.***************************************************************************************************
Selected Device : 4vlx15sf363-12
Number of Slices: 105 out of 6144 1%
Number of Slice Flip Flops: 134 out of 12288 1%
Number of 4 input LUTs: 128 out of 12288 1%
Number of bonded IOBs: 135 out of 240 56%
Number of GCLKs: 1 out of 32 3%
Minimum period: 5.212ns (Maximum Frequency: 191.872MHz)
Minimum input arrival time before clock: 1.445ns
Maximum output required time after clock: 3.921ns
Maximum combinational path delay: No path found
2.***************************************************************************************************
Selected Device : 4vlx15sf363-12
Number of Slices: 76 out of 6144 1%
Number of Slice Flip Flops: 134 out of 12288 1%
Number of 4 input LUTs: 72 out of 12288 0%
Number of bonded IOBs: 135 out of 240 56%
Number of GCLKs: 1 out of 32 3%
Minimum period: 4.793ns (Maximum Frequency: 208.616MHz)
Minimum input arrival time before clock: 1.445ns
Maximum output required time after clock: 3.921ns
Maximum combinational path delay: No path found
3.***************************************************************************************************
Selected Device : 4vlx15sf363-12
Number of Slices: 712 out of 6144 11%
Number of Slice Flip Flops: 135 out of 12288 1%
Number of 4 input LUTs: 1329 out of 12288 10%
Number of bonded IOBs: 135 out of 240 56%
Number of GCLKs: 1 out of 32 3%
Minimum period: 6.377ns (Maximum Frequency: 156.803MHz)
Minimum input arrival time before clock: 1.459ns
Maximum output required time after clock: 3.921ns
Maximum combinational path delay: No path found
*****************************And the Result from the Synplify
are*****************************************************************
1.***************************************************************************************************
Mapping to part: xc4vlx15sf363-10
Cell usage:
FD 134 uses
GND 1 use
MUXCY 1 use
MUXCY_L 127 uses
XORCY 128 uses
LUT1 125 uses
LUT2 4 uses
Mapping Summary:
Total LUTs: 129 (1%)
-----------------------------------------------------------------------------------------------------------------------
add|clk 1.0 MHz 143.8 MHz 1000.000
6.952 993.048 inferred Inferred_clkgroup_0
=======================================================================================================================
2.***************************************************************************************************
Mapping to part: xc4vlx15sf363-10
Cell usage:
FD 134 uses
GND 1 use
MUXCY 1 use
MUXCY_L 127 uses
XORCY 128 uses
LUT1 125 uses
LUT2 4 uses
Mapping Summary:
Total LUTs: 129 (1%)
Starting Clock Frequency Frequency Period
Period Slack Type Group
-----------------------------------------------------------------------------------------------------------------------
add1|clk 1.0 MHz 143.8 MHz 1000.000
6.952 993.048 inferred Inferred_clkgroup_0
=======================================================================================================================
3.***************************************************************************************************
Mapping to part: xc4vlx15sf363-10
Cell usage:
FD 134 uses
GND 1 use
MULT_AND 2 uses
MUXCY 1 use
MUXCY_L 63 uses
VCC 1 use
XORCY 63 uses
LUT1 61 uses
LUT2 1 use
LUT3 3 uses
LUT4 2 uses
Global Clock Buffers: 1 of 32 (3%)
-----------------------------------------------------------------------------------------------------------------------
add2|clk 1.0 MHz 139.9 MHz 1000.000
7.146 992.854 inferred Inferred_clkgroup_0
Can any one please help me why i am getting this much difference in
the result and what should be the real approch to write in HDL to get
most optimised result.
Thanks in advance
Article: 119591On May 22, 2:23 pm, luciorech <lucior...@gmail.com> wrote: > On 22 maio, 17:28, Alan Nishioka <a...@nishioka.com> wrote: > > > > > On May 22, 7:03 am, luciorech <lucior...@gmail.com> wrote: > > > > I'm using PLB to read and write 64bit data through burst transactions. > > > I can read and write data correctly, but watching the signals through > > > chipscope I can see a strange behavior: the PLB_MWrDAck and > > > PLB_MRdDAck don't occur in consecutive clock cycles. For instance, > > > during a 16 words burst read, instead of taking 16 clock cycles to > > > read all data after the bus has been granted to my peripheral, it > > > takes about 190 clock cycles. Did anyone have the same problem?? > > > PLB burst can indeed read/write in consecutive clock cycles. > > Perhaps your peripheral can't supply data fast enough? > > Assuming Xilinx ppc, the cache only reads/write 4 cycles (8 words) at > > a time. > > > Alan Nishioka > > Hi, > > I'm reading/writing directly from the DDR, so this can't be the > problem. The peripheral is also using the highest priority and I > double checked the signals, they are exactly how the IBM's Guide say. > > Lucio Rech But you still have not supplied enough information. What is on both sides of the bus transfer? Is one side your own custom peripheral? Are you trying to use IPIF? What speed are you running the bus? What chip are you using? Where in the world is Carmen Sandiego? Alan NishiokaArticle: 119592
Top posting to avoid the 4 pages of original post, included at the end...
The synthesizers appear generally not to be smart enough to group the
additions by size first. We can't ask them to do all the work but it
would have been nice to get better results without the extra nudge. The
nudge? In Synplify it's called a syn_keep and there's a similar
attribute in XST (though I know not what it's called.
The specific knowledge of the hardware can be used to get the "best"
results. Since we know 4-input LUTs are available in the Virtex-4
(larger in the Virtex-5) it would be "most" efficient to add in1 and in2
with LUTs then add that result with in3 and have in4 be a carr-in to
this last add.
While "temp" values are great for readability, there's no guaranteed
behavior when those values are combinatorial with no directives
attached; the synthesizer will look at the overall combinatorial "logic
cone" feeding the output reg.
To get you "best" result, us a 3-bit temp variable
(* syn_keep=1 *) wire [2:0] temp = in1+in2; // Verilog2k attribute syntax
and add this to th 64-bit vector with a carry-in
out <= in3 + temp + in4;
You are NOT guaranteed any build-up order by using the blocking operator
(=) and should generally use the non-blocking operator for your register
assignments. There are rare circumstances when the blocking operator is
useful, but they are rare. The synthesizer will still look at the
entire logic cone in an attempt to find a "best" solution.
Question: do you intend that a, b, c, and d actually be input registers?
The blocking operators would have completely ignored the input
register aspect given the order you coded them if you used out =
in1+in2+in3+in4; rather than out = result;. As it is, I'm surprised
both synthesizers gave you input registers. It's for this reason you
should NOT use the blocking operator!
So - let me know what you get with the syn_keep and the non-blocking
operator. Heck.... maybe the synthesizers will do a better job out of
the gate without the extra blocking operator confusion.
But be sure to figure out what the equivalent XST attribute is for the
syn_keep before relying on those results to match the "keep" intent.
- John_H
subint wrote:
> Hi guys,
> To know how the synthesizer behave,i wrote logic to add 4
> vectors in three different ways.And i got differnet result from the
> synthesizer(used both ISE and synplify).
> These are the three different approchs i made
> 1.***************************************************************************************************
> module add(
> input clk,
> input [1:0] a,b,
> input d,
> input [63:0] c,
> output reg [64:0] out
> );
>
> reg [1:0] in1,in2;
> reg in4;
> reg [63:0] in3;
> wire [64:0] result;
>
> always @ (posedge clk) begin
> {in1,in2,in3,in4}= {a,b,c,d};
> out= result;
> end
> assign result= in1+in2+in3+in4;
>
> endmodule
> 2.***************************************************************************************************
> module add1(
> input clk,
> input [1:0] a,b,
> input d,
> input [63:0] c,
> output reg [64:0] out
> );
>
> reg [1:0] in1,in2;
> reg in4;
> reg [63:0] in3;
> wire [64:0] temp;
> wire [64:0] temp2;
> wire [64:0] result;
>
> always @ (posedge clk) begin
> {in1,in2,in3,in4}= {a,b,c,d};
> out= result;
> end
>
> assign temp= in1+in2;
> assign temp2= temp+in4;
> assign result= temp2+in3;
>
> endmodule
> 3.***************************************************************************************************
> module add2(
> input clk,
> input d,
> input [1:0] a,b,
> input [63:0] c,
> output reg [64:0] out
> );
>
> reg [1:0] in1,in2;
> reg in4;
> reg [63:0] in3;
> reg [64:0] result;
>
> always @ (posedge clk) begin
> {in1,in2,in3,in4}= {a,b,c,d};
> out= result;
> end
> always @ (*) begin
> case({in4,in1,in2})
> 5'b00000: result= in3+3'b000;
> 5'b00001: result= in3+3'b001;
> 5'b00010: result= in3+3'b010;
> 5'b00011: result= in3+3'b011;
> 5'b00100: result= in3+3'b001;
> 5'b00101: result= in3+3'b010;
> 5'b00110: result= in3+3'b011;
> 5'b00111: result= in3+3'b100;
> 5'b01000: result= in3+3'b010;
> 5'b01001: result= in3+3'b011;
> 5'b01010: result= in3+3'b100;
> 5'b01011: result= in3+3'b101;
> 5'b01100: result= in3+3'b011;
> 5'b01101: result= in3+3'b100;
> 5'b01110: result= in3+3'b101;
> 5'b01111: result= in3+3'b110;
>
> 5'b10000: result= in3+3'b001;
> 5'b10001: result= in3+3'b010;
> 5'b10010: result= in3+3'b011;
> 5'b10011: result= in3+3'b100;
> 5'b10100: result= in3+3'b010;
> 5'b10101: result= in3+3'b011;
> 5'b10110: result= in3+3'b100;
> 5'b10111: result= in3+3'b101;
> 5'b11000: result= in3+3'b011;
> 5'b11001: result= in3+3'b100;
> 5'b11010: result= in3+3'b101;
> 5'b11011: result= in3+3'b110;
> 5'b11100: result= in3+3'b100;
> 5'b11101: result= in3+3'b101;
> 5'b11110: result= in3+3'b110;
> 5'b11111: result= in3+3'b111;
>
> endcase
> end
>
> endmodule
>
> And the results for these from the ISE are
> 1.***************************************************************************************************
> Selected Device : 4vlx15sf363-12
>
> Number of Slices: 105 out of 6144 1%
> Number of Slice Flip Flops: 134 out of 12288 1%
> Number of 4 input LUTs: 128 out of 12288 1%
> Number of bonded IOBs: 135 out of 240 56%
> Number of GCLKs: 1 out of 32 3%
>
>
>
> Minimum period: 5.212ns (Maximum Frequency: 191.872MHz)
> Minimum input arrival time before clock: 1.445ns
> Maximum output required time after clock: 3.921ns
> Maximum combinational path delay: No path found
>
> 2.***************************************************************************************************
> Selected Device : 4vlx15sf363-12
>
> Number of Slices: 76 out of 6144 1%
> Number of Slice Flip Flops: 134 out of 12288 1%
> Number of 4 input LUTs: 72 out of 12288 0%
> Number of bonded IOBs: 135 out of 240 56%
> Number of GCLKs: 1 out of 32 3%
>
>
> Minimum period: 4.793ns (Maximum Frequency: 208.616MHz)
> Minimum input arrival time before clock: 1.445ns
> Maximum output required time after clock: 3.921ns
> Maximum combinational path delay: No path found
> 3.***************************************************************************************************
> Selected Device : 4vlx15sf363-12
>
> Number of Slices: 712 out of 6144 11%
> Number of Slice Flip Flops: 135 out of 12288 1%
> Number of 4 input LUTs: 1329 out of 12288 10%
> Number of bonded IOBs: 135 out of 240 56%
> Number of GCLKs: 1 out of 32 3%
>
>
> Minimum period: 6.377ns (Maximum Frequency: 156.803MHz)
> Minimum input arrival time before clock: 1.459ns
> Maximum output required time after clock: 3.921ns
> Maximum combinational path delay: No path found
>
> *****************************And the Result from the Synplify
> are*****************************************************************
> 1.***************************************************************************************************
> Mapping to part: xc4vlx15sf363-10
> Cell usage:
> FD 134 uses
> GND 1 use
> MUXCY 1 use
> MUXCY_L 127 uses
> XORCY 128 uses
> LUT1 125 uses
> LUT2 4 uses
>
>
> Mapping Summary:
> Total LUTs: 129 (1%)
>
>
> -----------------------------------------------------------------------------------------------------------------------
> add|clk 1.0 MHz 143.8 MHz 1000.000
> 6.952 993.048 inferred Inferred_clkgroup_0
> =======================================================================================================================
> 2.***************************************************************************************************
> Mapping to part: xc4vlx15sf363-10
> Cell usage:
> FD 134 uses
> GND 1 use
> MUXCY 1 use
> MUXCY_L 127 uses
> XORCY 128 uses
> LUT1 125 uses
> LUT2 4 uses
>
>
> Mapping Summary:
> Total LUTs: 129 (1%)
>
> Starting Clock Frequency Frequency Period
> Period Slack Type Group
> -----------------------------------------------------------------------------------------------------------------------
> add1|clk 1.0 MHz 143.8 MHz 1000.000
> 6.952 993.048 inferred Inferred_clkgroup_0
> =======================================================================================================================
> 3.***************************************************************************************************
> Mapping to part: xc4vlx15sf363-10
> Cell usage:
> FD 134 uses
> GND 1 use
> MULT_AND 2 uses
> MUXCY 1 use
> MUXCY_L 63 uses
> VCC 1 use
> XORCY 63 uses
> LUT1 61 uses
> LUT2 1 use
> LUT3 3 uses
> LUT4 2 uses
>
>
> Global Clock Buffers: 1 of 32 (3%)
>
> -----------------------------------------------------------------------------------------------------------------------
> add2|clk 1.0 MHz 139.9 MHz 1000.000
> 7.146 992.854 inferred Inferred_clkgroup_0
>
>
> Can any one please help me why i am getting this much difference in
> the result and what should be the real approch to write in HDL to get
> most optimised result.
> Thanks in advance
Article: 119593On May 22, 1:25 pm, "bwilso...@gmail.com" <bwilso...@gmail.com> wrote: > This may seem like an elementary question/application, but I'll bring > it up nonetheless in hopes of getting a thorough understanding... > > In our design, there are 80MHz system-synchronous interfaces between > two FPGA's. There is a common clock source on the board with matched > trace lengths to each of the FPGA's. The clocks then go into DCM's > and the DCM 1x output clock is used to clock the IOB registers and > also used as internal feedback to the DCM. Can we [almost] guarantee > that the clocks coming out of the DCM's on the separate FPGA's are > near phase-aligned, assuming matched trace lengths coming in? These > are V4-LX160 parts. I was looking over the V4 user guide and couldn't > find a fitting clocking application example. It seems it can never be > fully guaranteed, since the DCM's deskew compensation on each of the > FPGA's will certainly differ, not to mention small process > variations. Since we have a 12.5ns period, I think we should have > room in our timing budget to absorb these small phase differences. I > will ensure that all the inputs and outputs utilize the IOB registers. > > If anyone could reassure me that this design is relatively common and > safe, and provide me with some information regarding the DCM output > clock relationships on the separate devices, I will feel much better. > I've definitely worked with these types of designs in the past, but > never fully understood why things just work. At 80 MHz setup timing is really easy to meet with up-to-date FPGA's. If there is any issue on this interface it will be hold-time related. To meet hold time requirements, the receiving FPGA should use the flip-flops in the IOB with the delay element enabled. This is the default for input flip-flops unless you specify NODELAY. This guarantees a 0 hold time vs. the external clock pin. When using the DCM as a clock source, your hold time will actually be negative. This means that as long as the input changes after the clock edge, or even at the clock edge, your input flip-flop will correctly sample the input as the value from the previous edge. Any additional delay after the clock is "gravy". Using a relatively slow I/O standard like LVTTL will guarantee your hold time even with unmatched clock traces and part-to-part DCM variations. i.e. your minimum clock to out delay on one part will be in the handful of nanoseconds range and you input hold time requirement will be negative, so you can live with a few nanosconds (that's a lot these days) of skew. As you describe your system I would guess the clock skew to be well under 1 nS. If you still don't believe this will work, add timing constraints to your inputs and outputs and take a look at the datasheet report at the end of your post P&R timing report. I have made similar interfaces without using DCM or DLL. Normally using a global clock input pin ensures a minimum of delay from the pin to the global clock net, and minimum delay also translates into minumum part-to-part skew (part-to-part skew is a percentage of total delay). Since the incoming clocks are phase-aligned, and assuming you have no other sources of data using these clocks than the FPGA's, the internal delay is irrelevant as long as the two FPGA's are relatively matched, or have long enough minimum clock to output delays to deal with the part-to-part variance. HTH, GaborArticle: 119594
On May 23, 3:10 pm, Alan Nishioka <a...@nishioka.com> wrote: > On May 22, 2:23 pm, luciorech <lucior...@gmail.com> wrote: > > > > > On 22 maio, 17:28, Alan Nishioka <a...@nishioka.com> wrote: > > > > On May 22, 7:03 am, luciorech <lucior...@gmail.com> wrote: > > > > > I'm using PLB to read and write 64bit data through burst transactions. > > > > I can read and write data correctly, but watching the signals through > > > > chipscope I can see a strange behavior: the PLB_MWrDAck and > > > > PLB_MRdDAck don't occur in consecutive clock cycles. For instance, > > > > during a 16 words burst read, instead of taking 16 clock cycles to > > > > read all data after the bus has been granted to my peripheral, it > > > > takes about 190 clock cycles. Did anyone have the same problem?? > > > > PLB burst can indeed read/write in consecutive clock cycles. > > > Perhaps your peripheral can't supply data fast enough? > > > Assuming Xilinx ppc, the cache only reads/write 4 cycles (8 words) at > > > a time. > > > > Alan Nishioka > > > Hi, > > > I'm reading/writing directly from the DDR, so this can't be the > > problem. The peripheral is also using the highest priority and I > > double checked the signals, they are exactly how the IBM's Guide say. > > > Lucio Rech > > But you still have not supplied enough information. What is on both > sides of the bus transfer? Is one side your own custom peripheral? > Are you trying to use IPIF? What speed are you running the bus? What > chip are you using? Where in the world is Carmen Sandiego? > > Alan Nishioka Well, I don't think I can answer the last question, so let's move to the others :) What I am trying to do is a 64bit burst transfer with variable length between my peripheral and a DDRAM, both connected to the PLB Bus (the memory uses the plb_ddr v2.00a). I'm stimulating the bus myself, thus not using the IPIF. The bus runs at 100 MHz and I'm using a Virtex2 Pro (XC2VP30). Lucio RechArticle: 119595
On May 23, 5:52 am, Test01 <cpan...@yahoo.com> wrote: > As per my understanding, you are suggesting an external transistor in parallel with the n-channel transistor to ground. The external transistor will turn on when the FPGA is driving low and will provide low resistance path to ground. No, no, no. I am not suggesting an external transistor. I just wanted to give you an understanding of the CMOS output structure. A very basic understanding. Peter Alfke > > Also you are suggesitng to raise the sink current value to 24 mA. Currently I am using 16 mA driver. I am assuming that 24 mA sink current will some how lower the resistance of the n-channel mosfet in the FPGA when it is on and help reduce the voltage drop across it. It will be great if you can expand on this. I am assuming that this solution will not require any external transistor to ground. > > Thanks for your feedback.Article: 119596
Test01, The voltage can not be made to go to 0 volts. That would be a 0 ohm impedance for the driver. There is no such thing as a FET with 0 ohms ON resistance. So, realizing this, what voltage do you actually need when driving low? AustinArticle: 119597
Hi everyone. I have a virtex II pro in a custom board (sundance board) and a Micron MT46V16M16. I use edk to create a design with PowerPC and the DDR. I select custom board and I finally get my design. The problems is the following: - sys_proc_reset only work with "PORT Dcm_locked = dcm_0_lock" and not with the default "PORT Dcm_locked = dcm_2_lock". I suppose that dcm_module blocks don't work fine. - This could be related with the second problem: Net fpga_0_GEN_DDR_CLK_FB LOC=; I have read the ucf file provide by the company and I don't find any feedback for the ddr. How could I resolve this?. How could I integrate DDR in my powerpc design?. It is very important, because my program has to be loaded in this sdram. ThanksArticle: 119598
Hi, Anyone had experience of creating a VxWorks Bootloader that will run on a Xilinx ML40x Evaluation Platform? I have created a bootloader and have loaded it into flash but it will not run from there. Any ideas why? ThanksArticle: 119599
On May 23, 9:00 am, subint <subin...@gmail.com> wrote:
> Hi guys,
> To know how the synthesizer behave,i wrote logic to add 4
> vectors in three different ways.And i got differnet result from the
> synthesizer(used both ISE and synplify).
> These are the three different approchs i made
> 1.***********************************************************************=
**=AD**************************
> module add(
> input clk,
> input [1:0] a,b,
> input d,
> input [63:0] c,
> output reg [64:0] out
> );
>
> reg [1:0] in1,in2;
> reg in4;
> reg [63:0] in3;
> wire [64:0] result;
>
> always @ (posedge clk) begin
> {in1,in2,in3,in4}=3D {a,b,c,d};
> out=3D result;
> end
> assign result=3D in1+in2+in3+in4;
>
> endmodule
> 2.***********************************************************************=
**=AD**************************
> module add1(
> input clk,
> input [1:0] a,b,
> input d,
> input [63:0] c,
> output reg [64:0] out
> );
>
> reg [1:0] in1,in2;
> reg in4;
> reg [63:0] in3;
> wire [64:0] temp;
> wire [64:0] temp2;
> wire [64:0] result;
>
> always @ (posedge clk) begin
> {in1,in2,in3,in4}=3D {a,b,c,d};
> out=3D result;
> end
>
> assign temp=3D in1+in2;
> assign temp2=3D temp+in4;
> assign result=3D temp2+in3;
>
> endmodule
> 3.***********************************************************************=
**=AD**************************
> module add2(
> input clk,
> input d,
> input [1:0] a,b,
> input [63:0] c,
> output reg [64:0] out
> );
>
> reg [1:0] in1,in2;
> reg in4;
> reg [63:0] in3;
> reg [64:0] result;
>
> always @ (posedge clk) begin
> {in1,in2,in3,in4}=3D {a,b,c,d};
> out=3D result;
> end
> always @ (*) begin
> case({in4,in1,in2})
> 5'b00000: result=3D in3+3'b000;
> 5'b00001: result=3D in3+3'b001;
> 5'b00010: result=3D in3+3'b010;
> 5'b00011: result=3D in3+3'b011;
> 5'b00100: result=3D in3+3'b001;
> 5'b00101: result=3D in3+3'b010;
> 5'b00110: result=3D in3+3'b011;
> 5'b00111: result=3D in3+3'b100;
> 5'b01000: result=3D in3+3'b010;
> 5'b01001: result=3D in3+3'b011;
> 5'b01010: result=3D in3+3'b100;
> 5'b01011: result=3D in3+3'b101;
> 5'b01100: result=3D in3+3'b011;
> 5'b01101: result=3D in3+3'b100;
> 5'b01110: result=3D in3+3'b101;
> 5'b01111: result=3D in3+3'b110;
>
> 5'b10000: result=3D in3+3'b001;
> 5'b10001: result=3D in3+3'b010;
> 5'b10010: result=3D in3+3'b011;
> 5'b10011: result=3D in3+3'b100;
> 5'b10100: result=3D in3+3'b010;
> 5'b10101: result=3D in3+3'b011;
> 5'b10110: result=3D in3+3'b100;
> 5'b10111: result=3D in3+3'b101;
> 5'b11000: result=3D in3+3'b011;
> 5'b11001: result=3D in3+3'b100;
> 5'b11010: result=3D in3+3'b101;
> 5'b11011: result=3D in3+3'b110;
> 5'b11100: result=3D in3+3'b100;
> 5'b11101: result=3D in3+3'b101;
> 5'b11110: result=3D in3+3'b110;
> 5'b11111: result=3D in3+3'b111;
>
> endcase
> end
>
> endmodule
>
> And the results for these from the ISE are
> 1.***********************************************************************=
**=AD**************************
> Selected Device : 4vlx15sf363-12
>
> Number of Slices: 105 out of 6144 1%
> Number of Slice Flip Flops: 134 out of 12288 1%
> Number of 4 input LUTs: 128 out of 12288 1%
> Number of bonded IOBs: 135 out of 240 56%
> Number of GCLKs: 1 out of 32 3%
>
> Minimum period: 5.212ns (Maximum Frequency: 191.872MHz)
> Minimum input arrival time before clock: 1.445ns
> Maximum output required time after clock: 3.921ns
> Maximum combinational path delay: No path found
>
> 2.***********************************************************************=
**=AD**************************
> Selected Device : 4vlx15sf363-12
>
> Number of Slices: 76 out of 6144 1%
> Number of Slice Flip Flops: 134 out of 12288 1%
> Number of 4 input LUTs: 72 out of 12288 0%
> Number of bonded IOBs: 135 out of 240 56%
> Number of GCLKs: 1 out of 32 3%
>
> Minimum period: 4.793ns (Maximum Frequency: 208.616MHz)
> Minimum input arrival time before clock: 1.445ns
> Maximum output required time after clock: 3.921ns
> Maximum combinational path delay: No path found
> 3.***********************************************************************=
**=AD**************************
> Selected Device : 4vlx15sf363-12
>
> Number of Slices: 712 out of 6144 11%
> Number of Slice Flip Flops: 135 out of 12288 1%
> Number of 4 input LUTs: 1329 out of 12288 10%
> Number of bonded IOBs: 135 out of 240 56%
> Number of GCLKs: 1 out of 32 3%
>
> Minimum period: 6.377ns (Maximum Frequency: 156.803MHz)
> Minimum input arrival time before clock: 1.459ns
> Maximum output required time after clock: 3.921ns
> Maximum combinational path delay: No path found
>
> *****************************And the Result from the Synplify
> are*****************************************************************
> 1.***********************************************************************=
**=AD**************************
> Mapping to part: xc4vlx15sf363-10
> Cell usage:
> FD 134 uses
> GND 1 use
> MUXCY 1 use
> MUXCY_L 127 uses
> XORCY 128 uses
> LUT1 125 uses
> LUT2 4 uses
>
> Mapping Summary:
> Total LUTs: 129 (1%)
>
> -------------------------------------------------------------------------=
--=AD--------------------------------------------
> add|clk 1.0 MHz 143.8 MHz 1000.000
> 6.952 993.048 inferred Inferred_clkgroup_0
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=AD=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> 2.***********************************************************************=
**=AD**************************
> Mapping to part: xc4vlx15sf363-10
> Cell usage:
> FD 134 uses
> GND 1 use
> MUXCY 1 use
> MUXCY_L 127 uses
> XORCY 128 uses
> LUT1 125 uses
> LUT2 4 uses
>
> Mapping Summary:
> Total LUTs: 129 (1%)
>
> Starting Clock Frequency Frequency Period
> Period Slack Type Group
> -------------------------------------------------------------------------=
--=AD--------------------------------------------
> add1|clk 1.0 MHz 143.8 MHz 1000.000
> 6.952 993.048 inferred Inferred_clkgroup_0
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=AD=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> 3.***********************************************************************=
**=AD**************************
> Mapping to part: xc4vlx15sf363-10
> Cell usage:
> FD 134 uses
> GND 1 use
> MULT_AND 2 uses
> MUXCY 1 use
> MUXCY_L 63 uses
> VCC 1 use
> XORCY 63 uses
> LUT1 61 uses
> LUT2 1 use
> LUT3 3 uses
> LUT4 2 uses
>
> Global Clock Buffers: 1 of 32 (3%)
>
> -------------------------------------------------------------------------=
--=AD--------------------------------------------
> add2|clk 1.0 MHz 139.9 MHz 1000.000
> 7.146 992.854 inferred Inferred_clkgroup_0
>
> Can any one please help me why i am getting this much difference in
> the result and what should be the real approch to write in HDL to get
> most optimised result.
> Thanks in advance
Some speculation ....
In the add2 architecture, I suspect that XST is implementing 8 (64 bit
+ "3 approx" bit) adders and muxing out the result where Synplicity
may have figured out to mux out the 3 bit vector and then add it to
the 64 bit input. This would fit with the much larger footprint given
by XST for add2. BTW, I own stock in Synplicity ;,)
It maybe that the the width of temp and temp2 in add1 maybe adding
noise to the statistics. The statistics after Map in P&R tools may
give better numbers and give apples to apples comparisons between the
synthesizers.
-Newman
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