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
"Leon Heller" <leon_heller@hotmail.com> writes: > "Petter Gustad" <newsmailcomp1@gustad.com> wrote in message > news:87zo5yp87r.fsf@filestore.home.gustad.com... > > > > I'm working on a program to aid me in the tedious allocation of pins > > for a Virtex-II device. But I need to obtain package information, > > presumably in machine readable form. I can use partgen to generate a > > plain ASCII file, but this does not contain any information regarding > > the bank number for each pin. Is there an ASCII (or documented binary > > file) file where I can find this information? > > http://www.xilinx.com/products/virtex/vpackages.htm Thanks, great. I'll just have to locate the same file for virtex2. So far I've only found PDF files. Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.comArticle: 36426
Rick Filipkiewicz <rick@algor.co.uk> writes: > A trick I use, given that the idea of publishing simple ASCII text > pinout/function files has escaped the attention of the chip industry since > its inception, is to fake a design that uses every pin of the device (incl. > clocks). Then a perl script can extract all the info you need from the post > P&R .pad and .par files. The only non-simple thing you need to do is make > sure there's at least one non-LVTTL IO standard so that the .par file has > the banking info. Smart. I'll look into that if I can't find any other easily readable files. Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.comArticle: 36427
In article <3BE9A84C.EAF321C4@xilinx.com>, Peter Alfke <peter.alfke@xilinx.com> wrote: >I see three good reasons why FPGA manufacturers do not incorporate DRAMs on >their chips: >Technical: DRAMs require different processing steps ( trench >capacitors, etc ), which would increase the cost of the composite >die. Not only that, but it does tend to slow down the logic processes a bit as well, as the transistors are optimized for lower leakage. There are talk of processes which use effectively different transistors for the DRAM cells as the rest of it, but that adds even more processing steps. Also, the real benefit of embedded DRAM is very high bandwidth by throwing lots of wires at the problem with independant banks with wide interfaces. How many FPGA applications can use 512 bit memory busses? >We have introduced many non-homogeneous features that are (almost) universally >appreciated: >Carry, LUT-RAM, BlockRAM, multipliers, digital clock management, >digitally-controlled output impedance, etc. And my favorite, the properly-paranoid bitfile encryption features on the Virtex II. :) -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 36428
Hi Nicolas, Well, what I am trying to do is to rise high the clk_rb_int signal when there is a rising edge on the we_intern or the re_intern signals. OK, it should be like the system clock signal (inverted), but shouldn't rise before we_intern or re_intern rise high as well. Please help me with this stuff. Best regards, Jaime. Nicolas Matringe <nicolas.matringe@ipricot.com> wrote in message news:<3BEA51A2.3A9FEDF9@ipricot.com>... > Tim Hubberstey a écrit : > > > > What it's complaining about in this rather confusing error > > message is that you have two different processes assigning to > > the same signal, clk_rb_inter. While this appears to be legal > > VHDL (assuming clk_rb_inter is of type std_logic) it is not > > synthesizable. You need to rewrite your code to combine the two > > rb_clock processes into one process. > > > > Further, you need to think about whether you really want to > > generate a clock using combinational processes like this. > > What puzzles me is the purpose of this description. clk_rb_inter should go high > only when there is an event on we_inter or re_inter and go low when nothing > happens? I can't find any sense in that, this would mean that it's high during > the event (which, ideally, takes no time).Article: 36429
jakab tanko wrote: > Hi all, > > Could somebody please tell me how to prevent the xlnx P&R > tool (Alliance 3.1i) from assigning the dedicated pins on a spartan2 > (D0/DIN, > BUSY/DOUT ..etc) to user IO, I want to keep the dedicated > pins dedicated...I spent the better part of the day searching the > xlnx site but got nowhere > Thanks, > jakab I'm not sure if I understood the question right. According to ds_001_4.pdf these pins are I/O pins, so there is no reason why not to use them. Did you lock the pins in the ucf file? If not, you should do it. If you don't care about a specific locking, you can just go to the project manager, under "Tools"->"Implementation" you'll find "Lock Device Pins". Propably you noticed that the IDE is working with two ucf files, one in the root directory of your project and one in "xproj/ver1/rev". The file in the root directory is only copied once to "xproj/ver1/rev", after the project data was cleared. The constraints editor and "Translate" work on the digged version. You can edit the pad locations by hand, the floorplanner is a great help, just move the cursor over a pad and it tells you the name of the pad. Hope that helps,wfr -jc-Article: 36430
"Nicholas Weaver" <nweaver@.........eley.EDU> wrote > Also, the real benefit of embedded DRAM is very high bandwidth by > throwing lots of wires at the problem with independant banks with wide > interfaces. How many FPGA applications can use 512 bit memory busses? Lots. 512-bit good, 32x1024 better, 1M even better. It a parallel world - ask your brain.Article: 36431
"Nicholas Weaver" <nweaver@CSUA.Berkeley.EDU> schrieb im Newsbeitrag news:9sem7m$1d5f$1@agate.berkeley.edu... > >Technical: DRAMs require different processing steps ( trench > >capacitors, etc ), which would increase the cost of the composite > >die. > > Not only that, but it does tend to slow down the logic processes a bit > as well, as the transistors are optimized for lower leakage. There > are talk of processes which use effectively different transistors for > the DRAM cells as the rest of it, but that adds even more processing > steps. Right, but how about a multichip package? Just move two dies into one package, add a hardmacro for the DRAM interface, maybe with some kind of FIFO and other luxury stuff. Taataaa, your FPGA fabric can right access damm fast DRAM. An since the connections are only some mm of bonding wire (or even just bonding pads if you stack the dies), you will get BIG improvements in HF properties. > Also, the real benefit of embedded DRAM is very high bandwidth by > throwing lots of wires at the problem with independant banks with wide > interfaces. How many FPGA applications can use 512 bit memory busses? ;-)) Are you kidding. As far as I can see, memorie bandwidth demand grows daily. -- MfG FalkArticle: 36432
In article <1005251212.18406.0.nnrp-13.9e9832fa@news.demon.co.uk>, Tim <tim@rockylogic.com.nospam.com> wrote: > >"Nicholas Weaver" <nweaver@.........eley.EDU> wrote >> Also, the real benefit of embedded DRAM is very high bandwidth by >> throwing lots of wires at the problem with independant banks with wide >> interfaces. How many FPGA applications can use 512 bit memory busses? > >Lots. 512-bit good, 32x1024 better, 1M even better. It a parallel >world - ask your brain. The problem is that the benefits of embedded DRAM only really occur when you have really wide busses for single accesses, and you have a pretty low level interface (you want to take advantage of the Sense-amps and column-caches and banking and the like). With an FPGA, it has to either be, A) A very small amount of silicon real estate (EG, the Virtex II bitfile cryptography, the multipliers) or B) useable by a huge number of customers (BlockRAMs) for it to be worth implementing. What percentage of the customers would rather have a single 2 Mbit (or maby 8 Mbit) memory with a 64-512 bit interface, with higher latency and (probably) single ported access, over say, 8 8kbit dual ported SRAMS with faster access and 1-16 bit flexible interfaces? This is the sort of tradeoff we are talking about. Instead, if you want Xilinx to spend silicon area and cost, probably a better thing to advocate would be a good DDR SDRAM interface as a hard macro combined with specialized circuits. It doesn't give you quite the memory bandwidth of the embedded DRAM solution, but it doesn't require special processing steps and it is useable by more people (since you can have MUCH larger memories). -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 36433
In article <9seqq0$131o71$1@ID-84877.news.dfncis.de>, Falk Brunner <Falk.Brunner@gmx.de> wrote: >Right, but how about a multichip package? Just move two dies into one >package, add a hardmacro for the DRAM interface, maybe with some kind of >FIFO and other luxury stuff. Taataaa, your FPGA fabric can right access damm >fast DRAM. An since the connections are only some mm of bonding wire (or >even just bonding pads if you stack the dies), you will get BIG improvements >in HF properties. Hmm, the problem is, MCMs are PRIIICEY. Also, I'd expect we will start seeing area pads on FPGAs really-soon-now, if not already, as they have several advantages, but which makes MCMs even more annoying. Perhaps a memory techonogy with area pads and vias, so you could sandwitch together two chips with area pads? But it does sound funky/expensive. >;-)) Are you kidding. As far as I can see, memorie bandwidth demand grows >daily. Except that it is fairly specialized memory bandwidth that process embedding gains. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 36434
Mike Treseler <mike.treseler@flukenetworks.com> writes: > Petter Gustad wrote: > > > > I'm working on a program to aid me in the tedious allocation of pins > > for a Virtex-II device. But I need to obtain package information, > > presumably in machine readable form. > > bsdl files include the pin names and designations. But they don't contain information about the banks... Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.comArticle: 36435
I don't have a problem with all dedicated pins, just the JTAG and master serial configuration pins; suppose one of your JTAG pins ends up shared with a data pin driven from a RAM (no tri-state RAM outputs); there will be a conflict on that pin with multiple drivers .... Anyway, the suggestion from Magnus with the .UCF file worked with a little twist: I also had to go and manualy delete the .map file then P&R again, othervise the map file would not reflect the changes Thanks for the answers, jakab Jens-Christian Lache <lache@tuhhN0ZPAM.de> wrote in message news:3BEAE54B.E04D79DF@tuhhN0ZPAM.de... > jakab tanko wrote: > > > Hi all, > > > > Could somebody please tell me how to prevent the xlnx P&R > > tool (Alliance 3.1i) from assigning the dedicated pins on a spartan2 > > (D0/DIN, > > BUSY/DOUT ..etc) to user IO, I want to keep the dedicated > > pins dedicated...I spent the better part of the day searching the > > xlnx site but got nowhere > > Thanks, > > jakab > > I'm not sure if I understood the question right. According to > ds_001_4.pdf > these pins are I/O pins, so there is no reason why not to use them. > Did you lock the pins in the ucf file? If not, you should do it. > If you don't care about a specific locking, you can just go to the > project manager, under "Tools"->"Implementation" you'll find > "Lock Device Pins". Propably you noticed that the IDE is working > with two ucf files, one in the root directory of your project and one > in "xproj/ver1/rev". The file in the root directory is only copied once > to "xproj/ver1/rev", after the project data was cleared. The constraints > > editor and "Translate" work on the digged version. You can edit the > pad locations by hand, the floorplanner is a great help, just move > the cursor over a pad and it tells you the name of the pad. Hope that > helps,wfr -jc- >Article: 36436
Rather than sampling the quadrature signal to extract a count pulse, consider using the quadrature signals to directly drive a counter scheme. While there might be some uncertainty of an edge of one of the two quadrature signals, a gray code style counter will only have one bit changing at any one time. By driving an internal up/down counter, the full rotation position can be captured. You then just need to sample this counter before you're 180 degrees out of phase with the count value; a 6 bit counter (0-63) gives you +/- 2 turns to work with before the value's ambiguous. anon7864 wrote: > I was wondering if anyone would like to share their experience in > doing quadrature encoder decoding in programmable logic. > > I am trying to deduce the minimal sampling rate for a hand-turned knob > that is a 2 channel, 16 position device. Currently I use a 12 state > Finite State Machine running at 6MHz to decode the encoders. I am > trying to reduce this to a more reasonable level to reduce power > consumption/heat. > > The spec sheet on the encoders we use says that the maximum RPM is > 100. A call to the factory reveals that: "Encoder section - 300 RPM > max, average manual operation is in the range of 1 to 16 RPM max. > ...tested (Per MIL-3786/39) @rate of 10 cycles per miv, which is 20 > RPM (One cycle is a rotation thru all positions and full return.)" > > I would like to design for worst case of 300RPM. > > position_time=200ms/16positions=13msec > > Shannon's theorem says that scan_rate=13msec/2=6msec (round down) > > This scan rate is not what I expected. I would have expected to scan > at around 1msec or less. I have proven this empirically on the > o-scope. > > So why in the encoder world, is the emperical to calculated comparison > so bad? What am I missing in my analysis? Am I just starting out with > a bogus initial RPM? What has your experience been on this problem?? > > Thanks in advance!Article: 36437
"Leon Heller" <leon_heller@hotmail.com> writes: > "Petter Gustad" <newsmailcomp1@gustad.com> wrote in message > news:87zo5yp87r.fsf@filestore.home.gustad.com... > > > > plain ASCII file, but this does not contain any information regarding > > the bank number for each pin. Is there an ASCII (or documented binary > > file) file where I can find this information? > > I found pinouts for the Spartan-II chips in the form of an Excel spreadsheet > somewhere on the Xilinx web site. It should be available for the Virtex > chips as well. After seeing the Virtex data in one of the other posts, I got a bit of hope, and went searching the Xilinx site for Spartan-II (which is what I need, more precise XC2S200-PQ208). This seems to be your Excel file(s), in .zip archive: http://www.xilinx.com/products/spartan2/s2_pin.zip Unfortunately(?) I have no Windows and no Excel, so I need ASCII or HTML. I am not aware of some anti-word like program for Excel. Could one of the @xilinx.com people here on this group get someone to do and excel-ectomy on these files and put the raw data on the site, like it is for Virtex? -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer - Intellectual Property is Intellectual RobberyArticle: 36438
What i really meant was: reg1_in<=func1(data_in); reg2_in<=func2(reg1_out); reg3_in<=func2(reg2_out); data_out<=func3(reg3_out); process begin wait until rising_edge(clk); reg1_out<=reg1_in; reg2_out<=reg2_in; reg3_out<=reg3_in; end process; Russell Shaw wrote: > > The Ashendon vhdl book describes pipelining, and others would too. > > In a process, you have: > > process > begin > reg1_in<=func1(data_in); > reg2_in<=func2(reg1_out); > reg3_in<=func2(reg2_out); > data_out<=func3(reg3_out); > > wait until rising_edge(clk); > reg1_out<=reg1_in; > reg2_out<=reg2_in; > reg3_out<=reg3_in; > end process; > > Marty wrote: > > > > I am working on a waveform generator that gets data from a dual-port RAM, > > and outputs it. It also has timing and jump instructions in the RAM data. > > The goal is to run at 50 MHz. The RAM, is 64K deep, and 15 nS access time. > > > > I can get the machine to simulate at 33 MHz, but not at 50 MHz. I think the > > way to solve this is to redesign the machine in a pipelined form. > > I have fit the non pipelined design into an Altera 7512AE. > > Some of the problems are getting the machine to do relative jumps - absolute > > jumps work. > > > > Does anyone know of any tools to help visualize or design a project like this? > > > > MartyArticle: 36439
Peter Alfke wrote: > > Russell Shaw wrote: > > > > > There's a .pdf on the altera site that categorizes FPGAs as things > > with segmented interconnects, whereas CPLDs don't have segments, > > making routing easier. > > Beware of marketing fluff. > They just wanted to indicate a distinction from Xilinx, while the two companies were embroiled in a > patent war. > "If it looks like an FPGA, behaves like an FPGA, is generally considered to be an FPGA", then they > might as well call it an FPGA, and admit that they copied the Xilinx concept. > Well, the patent fight is settled. Altera paid up, and perhaps they will now use a more reasonable > nomenclature. What was the patent over?Article: 36440
Andrew Gray wrote:
>
> Hi I declared a VHDL array in Maxplus as follows:
>
> type nik_table_i is array (0 to 63) of std_logic_vector(23 downto 0);
>
> constant Ni0 : nik_table_i :=
> ("000010110101000001001111","000010101011111010110100","00001010001001100111
> 1001","000010011000011111111011",...
>
> when I tried to compile I got the following error:
>
> Unsupported feature error: aggregates are supported only for types that map
> to an array of bits.
>
> Does any one know how to fix this
Obviously it wants bits. Other than trying another tool, maybe you
could use:
type nik_table_i is array (0 to 63) of bit_vector(23 downto 0);
Article: 36441Hi All, I am designing a system which contains a Xilinx XC95288XL CPLD. This CPLD has two functions. It must act as an FPGA loader, reading an FPGA image from ROM and writing it to a Xilinx Spartan II. The second function is for it to act as an I/O device for the Spartan (which is configured as a CPU). It is always in only one of these two modes. There are two possible reset levels on the board. A hard reset (equivalent to power cycling the board, but also possible via a button) should cause the CPLD to configure the Spartan II. A CPU reset (normal reset button) should cause the CPLDs I/O mode to reset itself (clear status and control registers). I would like to know if this is possible to do using the XC95288XL. On this chip there is only one GSR input. I would probably use this for the board reset input. Can I use a normal I/O pin for the second reset signal? Thanks very much, Dean ArmstrongArticle: 36442
Russell Shaw wrote: > What was the patent over? (This refers to the Xilinx vs Altera lawsuit.) I refuse to go into the merits and demerits of the case. But the main bone of contention was the Xilinx ( Ross Freeman ) patent #4 870 302 and its re-issue RE 34,363. I bet Altera would give you a different answer. Thank God it's over. Xilinx received a (token) $20M settlement from Altera. Only the lawyers got rich... Peter AlfkeArticle: 36443
Please forgive me if the formatting comes out strange due to line wraps...
The code below is Verilog compiled on Synplify, targeted to a Xilinx
Spartan-II device (latches are primitives in this device), and simulated with
Verilog-XL.
This approach should simplify quadrature encoder interface so you grap a
number only when you need the number. The width can be extended to very
large numbers if one likes, the delays simply increase. The number of CLBs
to implement the function is comfortably small.
Comments are appreciated.
module Quad ( QuadratureIn // This module takes in a quadrature signal
, Clk // and, upon receiving the sampling clock,
, BinaryOut // produces a 6 bit binary count.
); // (no reset or load is included in this code)
input [1:0] QuadratureIn; // Assuming up count is binary 0-1-3-2-0
input Clk; // Only used to sample the count
output [5:0] BinaryOut; // Combinatorial output of gray-to-binary
wire [5:0] BitEna; // Build latches where one MSB can change at a time
wire [5:0] Polarity; // [5:1] bits mirror QuadratureIn[1] or its inverse
reg [5:0] GrayCnt;
reg [5:0] GraySample;
integer i;
assign BitEna = { GrayCnt[3:0]==4'b0000 // MSbit enables different than
lower bits
, GrayCnt[3:0]==4'b1000 //
, GrayCnt[2:0]==3'b100 // Middle bits are enabled by the
, GrayCnt[1:0]==2'b10 // n lower bits equalling 1<<(n-1)
, GrayCnt[ 0]==1'b1 //
, 1'b1 }; // LSbit always tracks
QuadratureIn[0]
assign Polarity = { GrayCnt[4] // MSbit changes different from lower
bits
, ~GrayCnt[5] //
, ^~GrayCnt[5:4] // Middle bits depend only on the
, ~^GrayCnt[5:3] // polarity of the bits above them
, ^GrayCnt[5:2] // (be careful of the non-invert on
[1])
, 1'b0 }; // LSbit tracks QuadratureIn[0]
always @(QuadratureIn or BitEna or Polarity or GrayCnt)
for( i=0; i<6; i=i+1 )
GrayCnt[i] = BitEna[i] ? QuadratureIn[i>0?1:0] ^ Polarity[i] :
GrayCnt[i];
always @(posedge Clk) // Gray counters are inherently free of
metastability
GraySample <= GrayCnt; // allowing the BinaryOut to be a stable value
assign BinaryOut = GraySample ^ BinaryOut>>1; // gray-to-binary == xor
cascade
endmodule
Article: 36444Dear All, I am not clear about how to set the timing constraint in VirtexII device when using the build-in DCM. Currently I am using Synplify Pro 6.2 for synthesis and Xilinx ISE 3.308i for implementation. My Design use an external 40MHz clock, and is fed into a DCM. Within the design, I use both the 2x(clk2x) and 4x(clkfx) clock output of the DCM to clock the internal logics. In the Synplify Pro, there is a field for me to specify the required operating frequency. However no matter what value(e.g. 40MHz) I set, the implementation will treat all the clock(1x, 2x and 4x) have the same timing constraint of 40MHz(this is shown in the Place and Route Report after the implementation). As a result, I got a poor implementation result. Even I add the the following constraints in the UCF file, NET "CLOCK/dcm0_clk1x" TNM_NET = "CLOCK/dcm0_clk1x"; TIMESPEC "TS_CLOCK_dcm0_clk1x" = PERIOD "CLOCK/dcm0_clk1x" 25 ns HIGH 50 %; NET "CLOCK/dcm0_clk2x" TNM_NET = "CLOCK/dcm0_clk2x"; TIMESPEC "TS_CLOCK_dcm0_clk2x" = PERIOD "CLOCK/dcm0_clk2x" 12.5 ns HIGH 50 %; NET "CLOCK/dcm0_clkfx" TNM_NET = "CLOCK/dcm0_clkfx"; TIMESPEC "TS_CLOCK_dcm0_clkfx" = PERIOD "CLOCK/dcm0_clkfx" 12.5 ns HIGH 50 %; (the hierarchy is Top_level -> CLOCK ->DCM) the Place and Route Report still shown that the required frequency for all clock are 40Mhz. So, what should be the correct method to set the timing in my case? Thanks in advance. Regards, KennethArticle: 36445
Dear all,
Sorry, I added the following line to UCF file(I typed wrongly in my
previous post)
NET "CLOCK/dcm0_clk1x" TNM_NET = "CLOCK/dcm0_clk1x";
TIMESPEC "TS_CLOCK_dcm0_clk1x" = PERIOD "CLOCK/dcm0_clk1x" 25 ns HIGH
50%;
NET "CLOCK/dcm0_clk2x" TNM_NET = "CLOCK/dcm0_clk2x";
TIMESPEC "TS_CLOCK_dcm0_clk2x" = PERIOD "CLOCK/dcm0_clk2x" 12.5 ns HIGH
50%;
NET "CLOCK/dcm0_clkfx" TNM_NET = "CLOCK/dcm0_clkfx";
TIMESPEC "TS_CLOCK_dcm0_clkfx" = PERIOD "CLOCK/dcm0_clkfx" 6.25 ns HIGH
50%;
(the hierarchy is Top_level -> CLOCK -> DCM0,
and the net name of the 1x output is dcm0_clk1x,
2x output is dcm0_clk2x,
4x output is dcm0_clk4x)
Thanks again.
Regards,
Kenneth
Kenneth wrote:
>
> Dear All,
>
> I am not clear about how to set the timing constraint in VirtexII
> device when using the build-in DCM.
>
> Currently I am using Synplify Pro 6.2 for synthesis and Xilinx ISE
> 3.308i for implementation. My Design use an external 40MHz clock,
> and is fed into a DCM. Within the design, I use both the 2x(clk2x)
> and 4x(clkfx) clock output of the DCM to clock the internal logics.
>
> In the Synplify Pro, there is a field for me to specify the required
> operating frequency. However no matter what value(e.g. 40MHz) I set,
> the implementation will treat all the clock(1x, 2x and 4x) have the
> same timing constraint of 40MHz(this is shown in the Place and Route
> Report after the implementation). As a result, I got a poor
> implementation result.
>
> Even I add the the following constraints in the UCF file,
>
> NET "CLOCK/dcm0_clk1x" TNM_NET = "CLOCK/dcm0_clk1x";
> TIMESPEC "TS_CLOCK_dcm0_clk1x" = PERIOD "CLOCK/dcm0_clk1x" 25 ns HIGH 50
> %;
> NET "CLOCK/dcm0_clk2x" TNM_NET = "CLOCK/dcm0_clk2x";
> TIMESPEC "TS_CLOCK_dcm0_clk2x" = PERIOD "CLOCK/dcm0_clk2x" 12.5 ns HIGH
> 50 %;
> NET "CLOCK/dcm0_clkfx" TNM_NET = "CLOCK/dcm0_clkfx";
> TIMESPEC "TS_CLOCK_dcm0_clkfx" = PERIOD "CLOCK/dcm0_clkfx" 12.5 ns HIGH
> 50 %;
> (the hierarchy is Top_level -> CLOCK ->DCM)
>
> the Place and Route Report still shown that the required frequency
> for all clock are 40Mhz.
>
> So, what should be the correct method to set the timing in my case?
>
> Thanks in advance.
>
> Regards,
> Kenneth
Article: 36446
Hi,
"Russell Shaw" <rjshaw@iprimus.com.au> wrote in message
news:3BEB1D07.290AE5EF@iprimus.com.au...
>
>
> Andrew Gray wrote:
> >
> > Hi I declared a VHDL array in Maxplus as follows:
> >
> > type nik_table_i is array (0 to 63) of std_logic_vector(23 downto
0);
> >
> > constant Ni0 : nik_table_i :=
> >
("000010110101000001001111","000010101011111010110100","00001010001001
100111
> > 1001","000010011000011111111011",...
> >
> > when I tried to compile I got the following error:
> >
> > Unsupported feature error: aggregates are supported only for types
that map
> > to an array of bits.
> >
> > Does any one know how to fix this
>
> Obviously it wants bits. Other than trying another tool, maybe you
> could use:
>
> type nik_table_i is array (0 to 63) of bit_vector(23 downto 0);
I don't use this tool, but my guess is that it is unable to "handle"
array of "bit_vector" (or array of "std_logic_vector").
--
Srinivasan Venkataramanan
ASIC Design Engineer
Software & Silicon Systems India Pvt. Ltd. (An Intel company)
Bangalore, India, Visit: http://www.simputer.org)
Article: 36447Actually, I don't think it's a dumb idea at all. If processes keep scaling as they have been, we're going to keep seeing more and more things on-chip that previously wouldn't have been possible. Back when "programmable logic" meant PAL's, it would have been hard to convince me that we'd be putting 36Kb SRAMs, integrated 18-bit multipliers, etc. on a programmable logic chip, and next year they'll be integrating a full CPU core. Admittedly, integrated DRAM poses some interesting problems, but I think it's just a matter of time. I can already think of some fun applications... Luke Roth On Wed, 7 Nov 2001, Rob Finch wrote: > > Are there any fpga's containing high capacity dram's on chip ? There seem > to > > be quite a few people interfacing to external drams. > > > I've have thought it through more carefully and realized it just doesn't > make sense to provide on chip dram. Once again I have posted something and > regretted it. I've managed to prevent myself from posting most of my dumb > ideas, but this one escaped me. Sorry. > > > > > > >Article: 36448
Neil Franklin <neil@franklin.ch.remove> writes: > "Leon Heller" <leon_heller@hotmail.com> writes: > > > "Petter Gustad" <newsmailcomp1@gustad.com> wrote in message > > news:87zo5yp87r.fsf@filestore.home.gustad.com... > > > > > > plain ASCII file, but this does not contain any information regarding > > > the bank number for each pin. Is there an ASCII (or documented binary > > > file) file where I can find this information? > > > > I found pinouts for the Spartan-II chips in the form of an Excel spreadsheet > > somewhere on the Xilinx web site. It should be available for the Virtex > > chips as well. > > After seeing the Virtex data in one of the other posts, I got a bit of > hope, and went searching the Xilinx site for Spartan-II (which is what > I need, more precise XC2S200-PQ208). > > This seems to be your Excel file(s), in .zip archive: > > http://www.xilinx.com/products/spartan2/s2_pin.zip > > > Unfortunately(?) I have no Windows and no Excel, so I need ASCII or I don't use Windows either. Personally I can't see how people can consider an OS where a reboot is a part of the typical installation procedure as a serious EDA platform... > HTML. I am not aware of some anti-word like program for Excel. gnumeric, even though I've never actually used it myself. > Could one of the @xilinx.com people here on this group get someone to > do and excel-ectomy on these files and put the raw data on the site, > like it is for Virtex? It would be great if partinfo (or a similar) could generate most of the information found in the NPH file in a well documented and easily parsed ASCII format. Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.comArticle: 36449
--------------FB7271C5E57BD5D3B6691747 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Russell Shaw wrote: I found some other interesting things too: > > http://www.geocities.com/deepakgeorge2000/vlsi_book/Asynch1.pdf > http://www.geocities.com/deepakgeorge2000/vlsi_book/async_fifo2.pdf I looke at it and found it quite wordy. The author belabors metastability, and does not understand that the leading edge of Full and Empty is always a synchronous signal in the time domain of interest. Only the trailing edge is asynchronous, but there double-synchronizing is easy. Also, the generation of Grey addresses is described in an unnecessarily complicated way. I find my design so much simpler and less cluttered, if I may say so :-) See http://www.xilinx.com/support/techxclusives/fifo-techX18.htm Peter Alfke ( >30 years of FIFO experience, starting with the Fairchild 3341 ) --------------FB7271C5E57BD5D3B6691747 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <p>Russell Shaw wrote: <br>I found some other interesting things too: <blockquote TYPE=CITE> <br><a href="http://www.geocities.com/deepakgeorge2000/vlsi_book/Asynch1.pdf">http://www.geocities.com/deepakgeorge2000/vlsi_book/Asynch1.pdf</a> <br><a href="http://www.geocities.com/deepakgeorge2000/vlsi_book/async_fifo2.pdf">http://www.geocities.com/deepakgeorge2000/vlsi_book/async_fifo2.pdf</a></blockquote> I looke at it and found it quite wordy. The author belabors metastability, and does not understand that the leading edge of Full and Empty is always a synchronous signal in the time domain of interest. Only the trailing edge is asynchronous, but there double-synchronizing is easy. Also, the generation of Grey addresses is described in an unnecessarily complicated way. <br>I find my design so much simpler and less cluttered, if I may say so :-) <br>See <br><u><A HREF="http://www.xilinx.com/support/techxclusives/fifo-techX18.htm">http://www.xilinx.com/support/techxclusives/fifo-techX18.htm</A></u><u></u> <p>Peter Alfke ( >30 years of FIFO experience, starting with the Fairchild 3341 ) <br> </html> --------------FB7271C5E57BD5D3B6691747--
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