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
Kamal Patel <kamal.patel@xilinx.com> writes: [Alliance being discontinued.] > That is correct Robert. Does this mean that Solaris will no longer be supported as a place-and-route platform?Article: 33951
He said "During synthesis (Synopsys Design Comp.) such signals ...". Using a product such as Renior or Synplicity's HDL analyst it is very easy to see what is generated. I use synplicity. It offers an "RTL view" which gives you pre-mapping and a "Technology View" which shows you the post (synthesis) mapping. If you don't have a view like this, I'd strongly encourage you to pony up the extra dough for it. It has paid for itself many times over in both finding bugs as well as making sure I am getting the structure I want. Even without that, when you have a concern, it can pay to look at the edif netlist to isolate a problem to either the xilinx flow or your synthesis flow. Austin Franklin wrote: > I believe he said "during mapping" not during synthesis. I assumed by that > he meant it was post-route that he observed that happen...since I can't > imagine anyone taking the time to look manually through the text output of > the other tools...but who knows. > > "Ray Andraka" <ray@andraka.com> wrote in message > news:3B71C73B.AB1B1365@andraka.com... > > The lut wouldn't be inserted for routing by the synthesis. That happens > in > > PAR. The synthesis may be using it to duplicate a signal to reduce > loading. > > Check your fanout limit. It could also be there for connectivity if the > > output feeds carry chain primitives. > > > > Austin Franklin wrote: > > > > > Could it be using the LUT just for routing? > > > > > > "Pascal Merkel" <pascal.merkel@stud.uni-karlsruhe.de> wrote in message > > > news:3B682B4C.C799FCDE@stud.uni-karlsruhe.de... > > > > HI all, > > > > > > > > I have a design which consists of a data-path and a controller. Some > > > > controller signals drive two components of the data-path. During > > > > synthesis (Synopsys Design Comp.) such signals are divided in two > > > > seperate signals whereby always one of the both gets two inverters. > > > > During Mapping with XactM3.1 one of these inverters is removed because > > > > of being redundant. The other is mapped into a LUT, but this LUT don't > > > > invert, that's clear. But why all this is done? Does such a LUT act as > a > > > > buffer or is it unnecessary? > > > > > > > > Pascal > > > > -- > > -Ray Andraka, P.E. > > President, the Andraka Consulting Group, Inc. > > 401/884-7930 Fax 401/884-7950 > > email ray@andraka.com > > http://www.andraka.com > > > > -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 33952
If you want 12 bits out, then use a 15 bit path in your rotator and start with I=1/1/64675 and Q=0. At the output, round and discard the 3 lsbs. At each rotation you get a truncation of the results from the previous rotation. If you sum the maximum errors from each iteration, you'll find the sum of the errors due to truncation at each stage is bounded by roughly log2(number of iterations) lsbs, so with 12 iterations the max error from truncation is less than 16* the weight of the internal LSB. By dropping the LSBs you are essentially dividing the error. Antonio wrote: > Ray Andraka <ray@andraka.com> wrote in message news:<3B6FF9B2.78B90B90@andraka.com>... > > You'll get a quantization error in the cordic rotator regardless of whether you > > use a power of 2 or 1.646 on the cosine input. You can minimize the error by > > carrying a few extra bits below your intended output LSB internally. For > > example, if you want a 12 bit output, you might make the rotator 16 bits wide > > and then take out the 12 MSBs. The truncation error is bounded by roughly > > log2(iterations)*LSB weight. You'd get a similar truncation error in your post > > multiply if you do the gain correction afterwards. > > So definitively you suggest me to start with cosx = 1/1.64675 and to > use 12 bit for fractional part and one bit for the sign, and no bits > for the integer part, to earn a bit in this point is not so important > for your perspective ?? > > > > > Instead of trying to visualize it in radians, consider it in fractional > > > > revolutions. The accumulator value is then the fractional part of a > > > > revolution. If you have bits in the accumulator above those whch you take > > > > out as your phase angle, these would represent integer revolutions. > > > > > > what do you mean with fractional revolution, may you better explain > > > it, if possible with a practical example. > > > > The bit weights are such that the msb has a weight of pi, so for example, for a > > 4 bit field: > > 0000 = 0 > > 0100 = pi/2 > > 1000 = pi > > 1100 = 3pi/2 > > > > Then if your accumulator increment value is say, 5 you advance the phase angle > > by 5/16s of a revolution per clock, which is to say 5*pi/8. > > I'm now using the following Matlab code to produce the word I've to > put in the frequency word of the accumulator : > > clear all ; > close all ; > clc ; > > f_clk = 165e6 ; > f_out = 40e6 ; > n_bit_acc = 32 ; > n_bit_cordic = 12 ; > > fw = round( (f_out * 2^n_bit_acc) / f_clk ) > > fw_hex = dec2hex(fw) > fw_bin = dec2bin(fw) > > I obtain this frequency word > > fw_hex = > > 3E0F83E1 > > fw_bin = > > 111110000011111000001111100001 > > Is this right ?? Do you think it wil give me problem with the spurs > ??? > > Thanks ... > > Antonio D'Ottavio -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 33953
The double-inverters are inserted by synthesis. I have embedded FSMs in my design, a when they have identical outputs, only one of these is inverter-free, the other identical ones always get two inverters, and one of them is implemented in a LUT that "does nothing"(input=output). The other is removed due to the map report. So I think, Ray is right, and this is done to reduce loading. I'll check it. > "Ray Andraka" <ray@andraka.com> wrote in message > news:3B71C73B.AB1B1365@andraka.com... > > The lut wouldn't be inserted for routing by the synthesis. That happens > in > > PAR. The synthesis may be using it to duplicate a signal to reduce > loading. > > Check your fanout limit. It could also be there for connectivity if the > > output feeds carry chain primitives.Article: 33954
Oops, you are right. To add, you need the addends to be either signed
or unsigned. I also noticed that I fedback the unregistered theta, so I
fixed that. Also a style issue, I don't like ot use inouts unless there
is a tristate. Better to use an output and an internal signal for
feedback:
I think this ought to work.
library ieee;
use ieee.std_logic.1164.all;
use ieee.numeric_std.all; --use this rather than std_logic_arith and
signed. It is standard across
tools unlike the std_logic stuff
entity accumulatore is
port ( clk, load, clear : in std_logic;
theta : out
std_logic_vector(31 downto 0)
);
end accumulatore;
architecture acc_arch of accumulatore is
signal int_theta: unsigned(31 downto 0);
signal increment : unsigned(31 downto 0);
signal feedback : unsigned(31 downto 0);
signal reg_theta : unsigned(31 downto 0);
begin
feedback<= int_theta when load='1' else (others=>'0');
increment<= (others=>'0') when clear='1' else
"01000000000000000011000000000000";
reg_theta<= feedback + increment;
theta<= std_logic_vector(int_theta);
process(clk)
begin
if clk'event and clk='1' then
int_theta <= reg_theta;
end if;
end process;
end acc_arch;
Antonio wrote:
> Hy Ray,
> I tried your code but Aldec Active-HDL and Xilinx told me that this
> sum could not be performed on this operands, I tried to discover the
> problem but I've not found it .
>
> reg_theta<= feedback + increment;
>
> In any case coming back to my question , when you have a timing
> problem with your project, you only work on the VHDL or also use
> floorplanner and FPGA editor, I would want to understand if it's the
> case to well understand how them work or the advantage of to know it
> is really little.
>
> Oh, I never told before, excuse me all for my bad english .
>
> Thanks ..
>
> Antonio D'Ottavio
--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
Article: 33955Sounds like you don't have the xilinxcorelib either included, complied or pointed to as a library. I'm not a renior user, so I am not sure where to find its libraries. Peter Rauschert wrote: > Hi there, > > I've got a problem while trying to implement a fft16 (V1.0.3) > generated by the Xilinx Core Generator into Renoir (FPGA Advantage > 4.0) by Mentor. > > Using the generated .vho file I made an in-line component > configuration and when I try to generate HDL the following error > appears: > --- > "my_fft_core_rtl.vhd",line 42: Error, unit 'xilinxcorelib.vfft16_comp' > was not found or has errors (possibly in a dependency). > --- > But the libraries xilinxcorelib, unisim and simprim are compiled > correctly (without errors) by modelsim and mapped into renoir. > > Maybe someone has an idea and can help me to solve this problem ?? -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 33956
At least you'd be able to synthesize the AMS stuff then. You might also check to see if they still have a xilinx only synplicity. I think it used to be about 70% of the cost of a full seat. You'll still come up short on the simulation however. Last I tried, the annapolis simulation did not fare well at all under aldec because it is a bunch of linked scripts. You can use them to make aldec scripts to make it simulate properly. It will take a while but can definitely be done. James Brennan wrote: > Thanks Ray. I don't have access to Synplify nor Modelsim. I do have access > to Active-HDL and I read on the Aldec web page that it is now possible to > obtain Synplify with Active-HDL. To the best of your knowledge, would this > be a better solution than using Foundation? > > James. > > Ray Andraka <ray@andraka.com> wrote in message > news:3B714E5C.A8EEF4E1@andraka.com... > > I'm assuming then that you are NOT using synplicity and modelsim then. I > > think you have an uphill battle. The libraries have synplicity specific > > pragmas and attributes, the scripts are set up for synplicity and > modelsim. > > You've got a lot of modifying to do to get to a successful compile, > especially > > if you are using alot of the annapolis components and interfaces. It can > be > > done, but it is a mountain of work to get there. > > > > I got around this for one client by doing a top level design that > instantiated > > his design as a black box and put in the required annapolis stuff, pins > etc. > > I compiled the top level in the suggested tools flow and verified it with > a > > simple test circuit. This essentially gives him a pre-compiled socket for > his > > design. Now the client is free to modify his stuff, compile it as a black > box > > under whatever tool he wants. To put it in the design he just puts his > edif > > file where it can be found by the xilinx tools and place and route the > wrapper > > design. > > > > > > > > James Brennan wrote: > > > > > Hi all, > > > > > > Does anyone here have experience in using the Xilinx Foundation tools > with > > > Annapolis Micro Systems WILDCARD? I am looking at using Foundation to > > > develop designs for the WILDCARD and am wondering if > > > 1. This is possible. > > > 2. How "difficult" it is to get the two to work together. > > > > > > Thanks, > > > > > > James. > > > > -- > > -Ray Andraka, P.E. > > President, the Andraka Consulting Group, Inc. > > 401/884-7930 Fax 401/884-7950 > > email ray@andraka.com > > http://www.andraka.com > > > > -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 33958
Hello, The problem i'm getting is that when the program enter the IF Else loop......it losses the right value of register[] inside the IF's .....resulting a wrong value for data_word[] ..... but to chk even it enters the IF ElSE statements.....i put hardcoded values for data_word[] ...... and on simulation they appeard correct... so....it enters the IF statement fine...... so wats wrong with register[] here is the code: SUBDESIGN hib_card ( up_ale, /up_cs5, /up_wr, /up_rd, clk :INPUT; upad[7..0] :INPUT; ma[7..0], lb_word[7..0] :OUTPUT; ) VARIABLE ma[7..0] :DFFE; register[7..0] :DFFE; data_word[21..0] :DFFE; --reg2[7..0] :DFFE; p186_read :NODE; p186_write :NODE; data2 :NODE; data1 :NODE; data0 :NODE; hib :NODE; status :NODE; hib_write_data2 :NODE; hib_write_data1 :NODE; hib_write_data0 :NODE; hib_read_status :NODE; BEGIN ma[].clk = !up_ale; ma[] = (0, upad[7..1]); TABLE ma[] => hib , status , data2 , data1 , data0; H"40" => 0 , 0 , 0 , 0 , 0; H"41" => 0 , 1 , 0 , 0 , 0; H"42" => 1 , 1 , 0 , 0 , 0; H"43" => 1 , 0 , 0 , 0 , 1; H"44" => 1 , 0 , 0 , 1 , 0; H"45" => 1 , 0 , 1 , 0 , 0; END TABLE; p186_write = !/up_cs5 & !/up_wr; p186_read = !/up_cs5 & !/up_rd; IF p186_write THEN (register[], data_word[]).clk = !up_ale; data_word[7..0].ena = ma==(H"43"); data_word[15..8].ena = ma==(H"44"); data_word[21..16].ena = ma==(H"45"); --reg2[].clk = !up_ale; --reg2[].ena = VCC; register[] = upad[]; hib_write_data2 = data2 & hib & !status; hib_write_data1 = data1 & hib & !status; hib_write_data0 = data0 & hib & !status; IF hib_write_data2 THEN data_word[21..16] = register[5..0]; END IF; IF hib_write_data1 THEN data_word[15..8] = register[7..0]; END IF; IF hib_write_data0 THEN data_word[7..0] = upad[7..0]; END IF; ELSEIF !p186_read & p186_write THEN lb_word[] = upad[]; END IF; END; thx for ur help AbhimanyuArticle: 33959
The register DATA_WORD[] content is not used at all, and is "optimized out".
The compiler messages and the design report file both warn you of this optimization.
If you declare DATA_WORD[] to be an output from your design, then your result would surely be different.
A design note: NEVER gate a register clock. "Gate" the register's clock enable instead.
for example, your code reads:
p186_write = !/up_cs5 & !/up_wr;
IF p186_write == 0 THEN
register[].clk = !up_ale;
...
Instead, use a form similar to this:
register[].clk = !up_ale;
register[].ena = !p186_write;
Of course, register[] needs to be cast as DFFE rather than DFF in AHDL.
Hope this helps...
Bob Elkind, the e-team: fpga/design consulting
Abhimanyu Rastogi wrote:
> Hello,
>
> In this code data_word[21..0] is a 22bit word DFF...and the values are
> loaded into it at different !up_ale but it seem to not carry forward the
> values which it gets from the first clock to the second clock..... like if
> in the first clock i say data_word[21..16] = register[5..0] (here
> register[7..0] = 00111000) and at the second clock i say data_word[15..8] =
> register[7..0] (here register[7..0] = 11001100) and at the third clock i say
> data_word[7..0] = register[7..0] (here register[7..0] = 10101010) ....So now
> at the end my data_word[21..0] shoudl look like
> (data_word[21..0] = 1110001100110010101010)
>
> Ne kind of help would be appreciated.....
>
> Here is the code:--
> SUBDESIGN hib_card
> (
> up_ale, /up_cs5, /up_wr, /up_rd, clk :INPUT;
> upad[7..0] :INPUT;
> lb_word[7..0], band_config[2..0], data_out, ma[7..0] :OUTPUT;
> )
>
> VARIABLE
> ma[7..0] :DFFE;
> register[7..0] :DFFE;
> data_word[21..0] :DFF;
> pll_sel :NODE;
> p186_read :NODE;
> p186_write :NODE;
>
> BEGIN
>
> (ma[], data_word[]).clk = !up_ale;
> data_word[].clrn = VCC;
> ma[] = (0, upad[7..1]);
> p186_write = !/up_cs5 & !/up_wr;
> IF p186_write == 0 THEN
> register[].clk = !up_ale;
> --register[].ena = VCC;
> register[].d = upad[];
> lb_word[] = register[];
> CASE ma[] IS
> WHEN H"45" =>
> data_word[21..16] = register[5..0];
> %IF up_ale THEN
> ma[] = H"44";
> ELSE
> ma[] = H"45";
> END IF;%
> WHEN H"44" =>
> data_word[15..8] = register[7..0];
> %IF up_ale THEN
> ma[] = H"43";
> ELSE
> ma[] = H"44";
> END IF;%
> WHEN H"43" =>
> data_word[7..0] = register[7..0];
> data_out = VCC;
> %IF up_ale THEN
> ma[] = H"42";
> ELSE
> ma[]= H"43";
> END IF;%
> WHEN H"42" =>
> data_out = GND;
> IF register[3] THEN
> band_config[2..0] = register[2..0];
> pll_sel = VCC;
> ELSE
> pll_sel = GND;
> END IF;
> %IF up_ale THEN
> ma[] = H"41";
> ELSE
> ma[] = H"42";
> END IF;%
> WHEN OTHERS =>
> ma[] = H"45";
> END CASE;
> ELSE
> p186_read = !/up_cs5 & !/up_rd;
> lb_word[] = register[];
> END IF;
> END;
Article: 33960One Possible solution for this design would be to use a QuickLogic FPGA with an embedded PCI Interface. The QL5432 Has an embedded master/target PCI interface with about 1400 FF's. This should provide enough logic for your counters and a means to read back the data as a single chip solution. "Ali" <aelmousa@yahoo.com> wrote in message news:4eede02c.0108090350.1cc58020@posting.google.com... > Hello all, > > I need to fulfil the following requirements and I would appreciate any > help in deciding whether the use of an FPGA will be feasable. > > I have 40 sensors whose outputs are pulses but with a slow repitition > rate. > Each 4 (four) of these pulses i.e. from four different sensors, are > related to a specific event. What I need is to capture accurately the > time difference between the arrival of these pulses in each group. > > I am thinking of using a very fast free running reference counter and > latches. I will let the pulses act as a strobe to capture the output > values of the counter. By comparing the values in the latches I can > calculate the time difference between the arrival of the pulses. > > By my calculation, I need at least a 24 bit counter and thus 24 bit > latches. Also, I will need a precise 10Mhz clock. > > Thus I will require 40 (forty) 24 bit latches, and a free running 24 > bit binary counter. I wil need to be able to read all the output of > the latches. Also, 40 different inputs should be available. > > The question is: Is there a single FPGA or CPLD that has the > capability to implement the above? If no, how many will I need and > which types and makes? > > Also, will it be easy to connect the FPGA to a PC bus and control it? > I will also probably need a link to hardware interrupts to notify the > PC of the availability of data to be read from the latches. > > Any help or better ideas to implement the above will be greatly > appreciated. > > > Thank You > > AliArticle: 33962
You could easilly implement this design into a QuickLogic 5030 FPGA. This device has an embedded PCI core which could be programmed to trap the I/O address and the on chip user logic could decode the data for the 7 segment display. You can find data on the device at www.quicklogic.com . "Entwicklung" <entw@madex.com> wrote in message news:3B711BD4.D0A8F7E3@madex.com... > Hi All, > i'm looking for a Description how i can build a Display Card for showing > the Postcode from Bios on the PCI Bus. > The Card must look for an I/O Write Access on Adress 80H and then > display's the data on 2 7seg Display's as HEX. > Thank You for any Idea. > > -- > MfG > W. Philippi > Madex Electronic Components GmbH > >Article: 33963
Check the compiler messages for clues! IF p186_write THEN ... ELSEIF !p186_read & p186_write THEN <ignored by synthesizer because condition is never met> Alse, "ELSEIF" should be "ELSIF" Sheesh, check your compiler messages! There are clues there. And stop gating your clocks, please! -- Bob Elkind, the e-team Abhimanyu Rastogi wrote: > Hello, > > The problem i'm getting is that when the program enter the IF Else > loop......it losses the right value of register[] inside the IF's > .....resulting a wrong value for data_word[] ..... but to chk even it > enters the IF ElSE statements.....i put hardcoded values for data_word[] > ...... and on simulation they appeard correct... > so....it enters the IF statement fine...... so wats wrong with register[] > > here is the code: > SUBDESIGN hib_card > ( > up_ale, /up_cs5, /up_wr, /up_rd, clk :INPUT; > upad[7..0] :INPUT; > ma[7..0], lb_word[7..0] :OUTPUT; > ) > > VARIABLE > ma[7..0] :DFFE; > register[7..0] :DFFE; > data_word[21..0] :DFFE; > --reg2[7..0] :DFFE; > p186_read :NODE; > p186_write :NODE; > data2 :NODE; > data1 :NODE; > data0 :NODE; > hib :NODE; > status :NODE; > hib_write_data2 :NODE; > hib_write_data1 :NODE; > hib_write_data0 :NODE; > hib_read_status :NODE; > BEGIN > > ma[].clk = !up_ale; > ma[] = (0, upad[7..1]); > TABLE > ma[] => hib , status , data2 , data1 , data0; > H"40" => 0 , 0 , 0 , 0 , 0; > H"41" => 0 , 1 , 0 , 0 , 0; > H"42" => 1 , 1 , 0 , 0 , 0; > H"43" => 1 , 0 , 0 , 0 , 1; > H"44" => 1 , 0 , 0 , 1 , 0; > H"45" => 1 , 0 , 1 , 0 , 0; > END TABLE; > p186_write = !/up_cs5 & !/up_wr; > p186_read = !/up_cs5 & !/up_rd; > IF p186_write THEN > (register[], data_word[]).clk = !up_ale; > data_word[7..0].ena = ma==(H"43"); > data_word[15..8].ena = ma==(H"44"); > data_word[21..16].ena = ma==(H"45"); > --reg2[].clk = !up_ale; > --reg2[].ena = VCC; > register[] = upad[]; > hib_write_data2 = data2 & hib & !status; > hib_write_data1 = data1 & hib & !status; > hib_write_data0 = data0 & hib & !status; > IF hib_write_data2 THEN data_word[21..16] = register[5..0]; END IF; > IF hib_write_data1 THEN data_word[15..8] = register[7..0]; END IF; > IF hib_write_data0 THEN data_word[7..0] = upad[7..0]; END IF; > ELSEIF !p186_read & p186_write THEN > lb_word[] = upad[]; > END IF; > END; > > thx for ur help > AbhimanyuArticle: 33964
"Ray Andraka" <ray@andraka.com> wrote in message news:3B728E2B.623B832C@andraka.com... > He said "During synthesis (Synopsys Design Comp.) such signals ...". Er, ah...no...do go back and read what he said: "During synthesis (Synopsys Design Comp.) such signals are divided in two seperate signals whereby always one of the both gets two inverters." And then: "During Mapping with XactM3.1 one of these inverters is removed because of being redundant. The other is mapped into a LUT, but this LUT don't invert, that's clear. But why all this is done? Does such a LUT act as a buffer or is it unnecessary?" Which I read as the LUT mapping that he is having a problem with is done by the Xilinx tools...not the synthesis tools... The inversion is being done by systhesis, but that's not the question...the question was about the LUT, not the inversion, unless I'm just really reading what he said sideways... > Using a > product such as Renior or Synplicity's HDL analyst it is very easy to see what > is generated. I use synplicity. It offers an "RTL view" which gives you > pre-mapping and a "Technology View" which shows you the post (synthesis) > mapping. If you don't have a view like this, I'd strongly encourage you to pony > up the extra dough for it. It has paid for itself many times over in both > finding bugs as well as making sure I am getting the structure I want. I do use Synplicity with the RTL/Technology viewer...but that's not what he is doing from what I read. > Even without that, when you have a concern, it can pay to look at the edif > netlist to isolate a problem to either the xilinx flow or your synthesis flow. > > > Austin Franklin wrote: > > > I believe he said "during mapping" not during synthesis. I assumed by that > > he meant it was post-route that he observed that happen...since I can't > > imagine anyone taking the time to look manually through the text output of > > the other tools...but who knows. > > > > "Ray Andraka" <ray@andraka.com> wrote in message > > news:3B71C73B.AB1B1365@andraka.com... > > > The lut wouldn't be inserted for routing by the synthesis. That happens > > in > > > PAR. The synthesis may be using it to duplicate a signal to reduce > > loading. > > > Check your fanout limit. It could also be there for connectivity if the > > > output feeds carry chain primitives. > > > > > > Austin Franklin wrote: > > > > > > > Could it be using the LUT just for routing? > > > > > > > > "Pascal Merkel" <pascal.merkel@stud.uni-karlsruhe.de> wrote in message > > > > news:3B682B4C.C799FCDE@stud.uni-karlsruhe.de... > > > > > HI all, > > > > > > > > > > I have a design which consists of a data-path and a controller. Some > > > > > controller signals drive two components of the data-path. During > > > > > synthesis (Synopsys Design Comp.) such signals are divided in two > > > > > seperate signals whereby always one of the both gets two inverters. > > > > > During Mapping with XactM3.1 one of these inverters is removed because > > > > > of being redundant. The other is mapped into a LUT, but this LUT don't > > > > > invert, that's clear. But why all this is done? Does such a LUT act as > > a > > > > > buffer or is it unnecessary? > > > > > > > > > > Pascal > > > > > > -- > > > -Ray Andraka, P.E. > > > President, the Andraka Consulting Group, Inc. > > > 401/884-7930 Fax 401/884-7950 > > > email ray@andraka.com > > > http://www.andraka.com > > > > > > > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > >Article: 33965
Can you hardcode BAR decoding addresses as well as alleviate the need for PCI configuration to activate the device? "clevin1234" <clevin1234@home.com> wrote in message news:BQxc7.48752$m8.15202876@news1.rdc1.md.home.com... > You could easilly implement this design into a QuickLogic 5030 FPGA. This > device has an embedded PCI core which could be programmed to trap the I/O > address and the on chip user logic could decode the data for the 7 segment > display. > You can find data on the device at www.quicklogic.com . > > "Entwicklung" <entw@madex.com> wrote in message > news:3B711BD4.D0A8F7E3@madex.com... > > Hi All, > > i'm looking for a Description how i can build a Display Card for showing > > the Postcode from Bios on the PCI Bus. > > The Card must look for an I/O Write Access on Adress 80H and then > > display's the data on 2 7seg Display's as HEX. > > Thank You for any Idea. > > > > -- > > MfG > > W. Philippi > > Madex Electronic Components GmbH > > > > > >Article: 33966
The BAR's are implemented in the user logic so you can basically do anything you want with them. The device does not require PCI configuration for activation. "Austin Franklin" <austin@dark00room.com> wrote in message news:9kuaib$qq3$1@slb7.atl.mindspring.net... > Can you hardcode BAR decoding addresses as well as alleviate the need for > PCI configuration to activate the device? > > "clevin1234" <clevin1234@home.com> wrote in message > news:BQxc7.48752$m8.15202876@news1.rdc1.md.home.com... > > You could easilly implement this design into a QuickLogic 5030 FPGA. This > > device has an embedded PCI core which could be programmed to trap the I/O > > address and the on chip user logic could decode the data for the 7 segment > > display. > > You can find data on the device at www.quicklogic.com . > > > > "Entwicklung" <entw@madex.com> wrote in message > > news:3B711BD4.D0A8F7E3@madex.com... > > > Hi All, > > > i'm looking for a Description how i can build a Display Card for showing > > > the Postcode from Bios on the PCI Bus. > > > The Card must look for an I/O Write Access on Adress 80H and then > > > display's the data on 2 7seg Display's as HEX. > > > Thank You for any Idea. > > > > > > -- > > > MfG > > > W. Philippi > > > Madex Electronic Components GmbH > > > > > > > > > > > >Article: 33967
Really? How many did you order? They just quoted me a price of more than $4K. what's up with that? "Rotem Gazit" <rotemg@mysticom.com> wrote in message news:9kb5kb$3nf2s$1@ID-98676.news.dfncis.de...> > > > iii) The price for XC2V6000-4FF1152 is less than 3000US$ if you buy it from > Insight.Article: 33968
Even the enabling of them? "clevin1234" <clevin1234@home.com> wrote in message news:v9yc7.48863$m8.15212969@news1.rdc1.md.home.com... > The BAR's are implemented in the user logic so you can basically do anything > you want with them. > The device does not require PCI configuration for activation. > > > "Austin Franklin" <austin@dark00room.com> wrote in message > news:9kuaib$qq3$1@slb7.atl.mindspring.net... > > Can you hardcode BAR decoding addresses as well as alleviate the need for > > PCI configuration to activate the device? > > > > "clevin1234" <clevin1234@home.com> wrote in message > > news:BQxc7.48752$m8.15202876@news1.rdc1.md.home.com... > > > You could easilly implement this design into a QuickLogic 5030 FPGA. > This > > > device has an embedded PCI core which could be programmed to trap the > I/O > > > address and the on chip user logic could decode the data for the 7 > segment > > > display. > > > You can find data on the device at www.quicklogic.com . > > > > > > "Entwicklung" <entw@madex.com> wrote in message > > > news:3B711BD4.D0A8F7E3@madex.com... > > > > Hi All, > > > > i'm looking for a Description how i can build a Display Card for > showing > > > > the Postcode from Bios on the PCI Bus. > > > > The Card must look for an I/O Write Access on Adress 80H and then > > > > display's the data on 2 7seg Display's as HEX. > > > > Thank You for any Idea. > > > > > > > > -- > > > > MfG > > > > W. Philippi > > > > Madex Electronic Components GmbH > > > > > > > > > > > > > > > > > > > >Article: 33969
Hi all, concerning a prototype board serie we do have a configuration problem with ~ 50% of the board produced. The problem looks that the serial configuration in Master Mode does not take place the first time. An external Watchdog does reinitiate the configuration process ~ 1.6sec by forcing the program pin low. Then the Spartan-II device XC2S150 restart the configuration in Master Mode. Since there is no possibility the 'see' that the CRC for example is wrong, nothing happens the DONE-pin remains low. We use the ATMEL part 17LV010. Are there any known issues regarding this combination? In the Xilinx Tool chain I did NOT select anything special, just the defaults. Looking into the details with a scope I saw that the CCLK ~3.1 MHz. This is maybe a reasonable value. Any help would be appreciated! markus -- ******************************************************************** ** Meng Engineering Telefon 056 222 44 10 ** ** Markus Meng Natel 079 230 93 86 ** ** Bruggerstr. 21 Telefax 056 222 44 10 ** ** CH-5400 Baden Email meng.engineering@bluewin.ch ** ******************************************************************** ** Theory may inform, but Practice convinces. -- George Bain **Article: 33970
This is a multi-part message in MIME format.
--------------823961AF93252A805416DD15
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Ray Andraka wrote:
> Rick Filipkiewicz wrote:
>
> > Ray Andraka wrote:
> >
> > > Paul Smart wrote:
> > >
> > > > Hi Ray,
> > > >
> > > > In principle, I agree with much of what you have said.
> > > >
> > > > On Tue, 31 Jul 2001 01:47:49 GMT, Ray Andraka <ray@andraka.com> wrote:
> > > >
> > > > >
> > > > >It is behavioral in the sense that you can't go back and run that vhdl
> > > > >through the tools to regenerate the design (wrong library). It doesn't
> > > > >map directly back into the unisim primitives.
> > > > >
> > > > >
> > > > Is there any way to take a modified verilog simulation file and put it
> > > > back through to create a modified design?
> > >
> > > not any easy paths that I am aware of. You can remap the simprims into
> > > unisims, but it is a very painful process. Probably less work starting on a
> > > fresh design.
> >
> > I think its actually impossible to do this since there is a lot of information loss
> > in the process of creating a Xilinx post-route sim netlist. e.g. all the various
> > 2-way muxes, MUXF5, MUXF6, MUXCY, get turned into a single simprim X_MUX2. At least
> > this is true for the flattened output from NGD2VER that I use. The ``re-create
> > hierarchy'' mode might be better but a lot of that is still flattened.
>
> THis is why I said is is a very painful process. You can get to something that is
> functional but may not map very well into the architecture fairly easily. Like you
> point out, you lose all the architectural features like the carry chain stuff. You
> also lose any placement you might have had.
>
> I suspect part of the reason for using different libraries is a (misguided?) attempt to
> retain design security.
Ray,
There were two main reasons the decision was made to go to different front-end and
back-end libraries however design security was not one of them (no matter how misguide that
may seem). One reason was to prevent people from shooting themselves in the foot by trying
to re-synthesize and re-implement a structural simulation netlist back into the tools.
Back in the XACT days, we did have the same library for the front-end and back-end
simulation and believe it or not, for many good and bad reasons, people would try to use
the simulation netlist in order to re-implement the design. Many time this would result in
errors however with enough messaging of the netlist, you can get around the errors however
almost always end up with a worse implementation of the design. As previously mentioned,
things like carry chains get distorted/broken, MUXs would get improperly mapped,
optimization was bad, and sometimes a non-working design would result from this action so
having a different library helps prevent this from happening and helps reduce some of the
support burden when people used to attempt this.
The other main reason is when this decision was made some five years ago, there was
much more of a distinction from front-end design to back end design. What I mean by this
is that in the earlier days of synthesis, many tools output logical XNF netlists in terms
of AND and OR gates and were less aware of target technology. Even in the schematic world,
if you wanted to map a function to a LUT you would first create the logical structure using
gates and the use FMAPs and HMAPs to direct the mapper to place it into a LUT. This was
fine for design creation however when creating a structural timing representation of the
design for back-end simulation, it made much more sense to represent the design in a more
physical manner which meant changing gates to LUTs. This way the timing annotation much
more accurately modeled to the delays seen in silicon. So the decision was made to have
one logical front-end library (UNISIM) and a much smalller physical library (SIMPRIM). Now
this is not nearly as much of an issue as schematic is not used very often anymore (I am
not trying to open a schematic vs. synthesis debate here so do not take this statement too
seriously) and most synthesis tools now output much more technology specific netlists
(LUTs, CYMUX, MUXFx, etc.) however when this decision was made, that was not the case.
For the most part I think this having two libraries has worked out quite well and has
not been much of an issue for most customers. Starting with the next release of software,
4.1i, we will even start supporting 3rd party formal verification tools and 3rd party
static timing analysis tools using these Simprim libraries. You will probably see more and
more support for traditional ASIC verification tools support from Xilinx as time goes on
and so far these libraries have not been much of a hinderance for this support.
> > Parenthetically I've always wondered why Xilinx don't follow standard ASIC practice
> > here and use the same lib for the design's EDIF netlist and the port-route sim one
> > ? My - guessed - answer is that post-route sim is done much less frequently for
> > FPGAs so the effort is not worth it, the unisims lib is far bigger than simprims.
Traditionally, timing simulation was not used too often for FPGAs since you don't really
pay any penaties to just "try the design out" in the silicon as you do with a standard ASIC
flow. As designs grow in complexity and size however, I do not see how many engineers can
get away without timing simulation. I personally would spend most of my simulations cycles
in the RTL-land and spend a good amount of time specifying and verifying time-specs using
static timing analysis however timing simulation can show problems easily overlooked in the
previously mentioned verification methods and seeing my design pass timing simulation would
give me the added assurance that my design will work as expected in the silicon which is
obviously the end goal here.
I guess enough has been said here. Just thought I would give some clarification to what
has been said from my own experiences and opinions.
-- Brian
>
>
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930 Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
--------------823961AF93252A805416DD15
Content-Type: text/x-vcard; charset=us-ascii;
name="brian.philofsky.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Brian Philofsky
Content-Disposition: attachment;
filename="brian.philofsky.vcf"
begin:vcard
n:Philofksy;Brian
x-mozilla-html:TRUE
org:Xilinx, Inc.;System Level & Alliance Marketing
adr:;;;;;;
version:2.1
email;internet:brian.philofsky@xilinx.com
title:Technical Marketing Engineer
fn:Brian Philofksy
end:vcard
--------------823961AF93252A805416DD15--
Article: 33971
This is the initial release of the MPGA, an open source meta-FPGA.
http://ce.et.tudelft.nl/~reinoud/mpga/README.html
>From the README:
---------------------------------------------------------------------
MPGA - Meta Programmable Gate Array
Version 0
This is an open source design for an FPGA to be implemented on an
FPGA; a 'meta-FPGA' (hence the name). If you wonder whether something
like that makes any sense, then chances are that it won't be useful
to you. However, this MPGA has a few nice properties that 'real'
FPGAs lack. It has open programming specs, and a bitstream format
that's amazingly easy to edit. This means that you aren't bound by
limitations of vendor tools. (If you wonder what those limitations
are, don't worry, be happy;). The open specs and design can also be
especially attractive for open source tool development. Another
notable feature is that you can (re)program an MPGA as fast as you
like (and are willing to spend bandwidth on). This is rather nice for
reconfigurable computing or evolutionary design experiments.
The density of the current MPGA is actually fairly high: one MPGA CLB
is implemented using one Virtex CLB. Of course, the MPGA CLB can't
offer all the functionality of a Virtex CLB, but does offer FFs,
LUTs, and (independent) global routing. Local routing is probably the
weakest part of the current design, a fair percentage of CLBs will be
needed for local routing through the cell. Also, I'm unsure how well
automatic routers will be able to deal with the limited routing
structure. And don't expect MPGA designs to achieve particularly high
clock frequencies: there will be many levels of logic in most
designs, because routing switches are implemented with LUTs.
...
---------------------------------------------------------------------
- Reinoud
(Spam goes to wanabe, mail to wanadoo!)
Article: 33972This is a multi-part message in MIME format. --------------6099E89EAB4D24EF6B6A7866 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Krishnakumar Rao wrote: > I am using Leonardo Spectrum (Version: v20001a2.75 (Release > Production, compiled Aug 29 2000 at 12:35:44)). I have done Post > Synthesis Simulation for Xilinx Virtex devices using Unisim VHDL > Library. But using this library I am unable to do post synthesis > simulation for other Xilinx family devices. Can someone tell me > whether it is possible to do Post Synthesis Simulation for Xilinx > Spartan and 4000 series devices. If so please let me know how this can > be done ? In theory, you should be able to do a post-synthesis simulation targeting a Spartan or 4000 device although I have not personally tried it with Leonardo 2001a. Could you be more specific with the problems you are seeing? -- Brian --------------6099E89EAB4D24EF6B6A7866 Content-Type: text/x-vcard; charset=us-ascii; name="brian.philofsky.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Brian Philofsky Content-Disposition: attachment; filename="brian.philofsky.vcf" begin:vcard n:Philofksy;Brian x-mozilla-html:TRUE org:Xilinx, Inc.;System Level & Alliance Marketing adr:;;;;;; version:2.1 email;internet:brian.philofsky@xilinx.com title:Technical Marketing Engineer fn:Brian Philofksy end:vcard --------------6099E89EAB4D24EF6B6A7866--Article: 33973
This is a multi-part message in MIME format. --------------35B3DA5ED703EA6925F7211D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rick Filipkiewicz wrote: > Petter Gustad wrote: > > > Phil Hays <spampostmaster@home.com> writes: > > > > > Kamal Patel wrote: > > > > > > > > That is correct Robert. The ISE GUI ... > > > > > > I hope that batch files still will work. > > > > I hope so too (I assume you mean all the individual command line > > tools). The only GUI program I use is floorplanner. However, I would > > love to see the tools available under Linux rather than a GUI with a > > talking chip (cousin of the MS paper-clip)... > > > > Petter > > -- > > ________________________________________________________________________ > > Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.com > > O.k. Xilinx persons on CAF: > > o (original question) Will it still be possible to run the command line > tools in ISE after the demise of Alliance ? Yes. Commandline is still there. Xglow is still there as well for those who like to use that. I would probably more upset to see command-line go away than you would be. > o Will it be possible to buy a version of Foundation ISE *without* FPGA > Express for the same price as the Alliance-up-to-XCV1000 package (~$1400) ? I can't speak about pricing because I don't know. My understanding is that there will be a version without Express so we will not be forcing that on you. > Even better would be a version that dumps the overall GUI altogether for > those of us that never use it. I doubt we will do that but if you don't want the GUI, don't use it. I see the benefits from this as well, (less disk space mainly), but to package up another version of software, test it, create another installer, etc will probably not happen. > A ``serving suggestion'' that would greatly > increase the flexibility of the tool: > > o Use the ``Tcl'' scripting language like the rest of the EDA industry's > tools - even Synopsys. [Better yet than that would be Perl but the EDA world > seems to have settled on Tcl ... HoHum]. I hear you but here is my suggestion. If all you are looking at is an easier way to run the tools from command-line, then I suggest using XFlow if you do not already. If you are looking for additional pre-processing or post-processing capabilities that TCL can give you (or Perl for that matter), nothing is stopping you. For TCL, I suggest using the synthesis tool or simulation tool's TCL capability to invoke our tools either using Xflow or calling the individual sub-programs using the TCL exec construct. There is not much capability we can add for you by incorperating TCL into our software that most likely is already offered by your synthesis or simulation tool. If Perl is your thing, then I suggest installing it to your machine and using it to call our tools. Many people have and will do this. I personally have used CSH for most of my career to do the same as above but more recently starting using TCL and now have a set of scripts in TCL to do most of the things I used to use CSH for. I am not saying Xilinx should or should not, will or will not ever have TCL capability built into the tool. All I am saying is that most likely, you can do everything you wanted to do in TCL now without this capability directly built into our tools. > At a stroke this would remove any real need for an overarching GUI except > for those processes that are inherently visual - Floorplanner, FPGAEditor. > It also allows the creation of arbitrary synth+P&R scripts (even integrate > a post-synth simulation run ...). e.g. the MPPR option to PAR would just be > replaced with a ``for'' loop. Agreed. > ... and of course for those benighted souls who insist on a > push-the-big-green-button approach the ISE GUI would be written in Tcl's > graphical companion ``Tk''. Agreed here too but do not see why Tk would have to be used other than the fact it would allow the bolder people out ther to customize the GUI. I agree that ModelSim has a good thing in that respect but for most people, it would not make a difference if it was Tk, C++, Java or whatever that created the GUI, just that it works right. -- Brian --------------35B3DA5ED703EA6925F7211D Content-Type: text/x-vcard; charset=us-ascii; name="brian.philofsky.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Brian Philofsky Content-Disposition: attachment; filename="brian.philofsky.vcf" begin:vcard n:Philofksy;Brian x-mozilla-html:TRUE org:Xilinx, Inc.;System Level & Alliance Marketing adr:;;;;;; version:2.1 email;internet:brian.philofsky@xilinx.com title:Technical Marketing Engineer fn:Brian Philofksy end:vcard --------------35B3DA5ED703EA6925F7211D--Article: 33974
This is a multi-part message in MIME format. --------------85CC7C75C3A724F9AE39CE65 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit szekit wrote: > What is the CAE library used for? The CAE library CD from Xilinx contains libraries for the supported 3rd party schematic and syntheiss tools in which Xilinx creates the libraries for. > I generated an EDIF file on my sun workstation from cadence and then put it through the Xilinx's design manager (alliance) on my PC but it generates errors stating some components are not expanded. Do I have to install the CAE library on the sun's machine and reference to this library when I try to generate the EDIF with cadence or synopsys? I assume you mean Cadence Concept-HDL? If so, you do need to install the Concept libraries before you can create a schematic and netlist it to EDIF. In terms of Synopsys, if you are referring to Design Compiler this is also true (expept you obviously install the DC libraries). I suggest referring to the Xilinx documentation as you must also become familiar with the flow and setups for Xilinx in ordre to sucessfully run a design through. http://toolbox.xilinx.com/docsan/3_1i/ > What kind of setup and environment (libraries) do I need to install to have a design flow such that I can generate an EDIF from cadence or synopsys on sun's machine and then pass the EDIF to xilinx's design manager on a PC? Again, look at the documentation. If you sucessfully create and EDIF file on your Sun workstation, there is not reason you can't implement that EDIF file on your PC. -- Brian > Your help is much appreciated!!!! --------------85CC7C75C3A724F9AE39CE65 Content-Type: text/x-vcard; charset=us-ascii; name="brian.philofsky.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Brian Philofsky Content-Disposition: attachment; filename="brian.philofsky.vcf" begin:vcard n:Philofksy;Brian x-mozilla-html:TRUE org:Xilinx, Inc.;System Level & Alliance Marketing adr:;;;;;; version:2.1 email;internet:brian.philofsky@xilinx.com title:Technical Marketing Engineer fn:Brian Philofksy end:vcard --------------85CC7C75C3A724F9AE39CE65--
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