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
I'm having a problem with a state machine written in verilog that I need to
get into vhdl. My simulation license only allows vhdl and I can't afford
one that will do both. The problems is worse because it simulates just
fine, but fails Xilinx ppr. But it has also run Xilinx ppr, so I'm thinking
it involves the work directory and "cleanup project files" too. Perhaps if
I ppr using the verilog file and then switch to the vhdl file it works fine
until I "cleanup project files" and the fails from that point on? Anyway,
the verilog code:
always @ (CurrentState or count or rxstatus or rxelecidle or rx_locked or
align_det or sync_det)
begin : SM_mux
count_en = 1'b0;
NextState = host_comreset;
linkup_r = 1'b0;
txcomstart_r =1'b0;
txcomtype_r = 1'b0;
txelecidle_r = 1'b1;
send_d10_2_r = 1'b0;
send_align_r = 1'b0;
rxreset = 1'b0;
case (CurrentState)
host_comreset :
begin
if (rx_locked)
begin
was replaced with the vhdl code:
SM_mux : PROCESS
BEGIN
WAIT ON CurrentState, count, rxstatus, rxelecidle,
rx_locked, align_det, sync_det;
count_en <= '0';
NextState <= host_comreset;
linkup_r <= '0';
txcomstart_r <= '0';
txcomtype_r <= '0';
txelecidle_r <= '1';
send_d10_2_r <= '0';
send_align_r <= '0';
V2V_rxreset <= '0';
CASE CurrentState IS
WHEN (X"0") => -- state 0 = host_comreset
IF (rx_locked = '1') THEN
and the vhdl error from Xilinx ppr points to the line with "SM_mux : PROCESS
" and says:
"Bad condition in wait statement, or only one clock per process."
I'd be grateful if someone could help me out.
Thanks
Dan
Article: 129801austin wrote: > Don't forget some attackers have infinite labor, and infinite patience. > My favorite example is when the students took over the American Embassy > in Iran, and then put back together all of the shredded secret documents > ... a massive task, but just a big puzzle after all (and one that could > be, and was, solved). BTW, this is not even a problem of labor and patience anymore: http://tinyurl.com/2e2lyf :) cu, Sean -- My email address is only valid until the end of the month. Try figuring out what the address is going to be after that...Article: 129802
You could have worse problems in store for you. Your verilog and vhdl code may not perform the way you think they will. You have only posted a subset of the code so I can't tell if the difference will bite you now or only in the future when you change your code. In your verilog code you are use blocking assignments. This means in the future any use of that reg will have the new value that was recently set. In the VHDL your code is assigning signals, signals do not get updated until the process finishes executing. Which means references to those signal names will use the old value for computations not the new value like the verilog code does. A general rule of thumb when converting between vhdl<->verilog blocking converts to variables and non-blockign converts to signals. This probably isn't an issue right now. You haven't gotten far enough into the process for these difference to show up. They wouldn't show up as an error message. They normally show up as 2-3 days of tearing you hair out trying to figure out why the code isn't working as expected. You can attempt to bypass your current error by using: SM_mux : process(CurrentState, count, rxstatus, rxelecidle,rx_locked, align_det, sync_det) and eliminating the "WAIT ON" line. it will still be equivalent, but the xilinx software may be getting confused on the "wait" statement and tring to infer flipflops or multiple clocks instead of pure combinational logice. Granted, this is a guess based on the code snippets. The full RTL could get you better answers. You also want to post on the comp.lang.vhdl and comp.lang.verilog news groups. You might get more feed back. "Dan K" <danielgkNOSPAM@visi.com> wrote in message news:QHEzj.6$1g.1@fe24.usenetserver.com... > I'm having a problem with a state machine written in verilog that I need > to get into vhdl. My simulation license only allows vhdl and I can't > afford one that will do both. The problems is worse because it simulates > just fine, but fails Xilinx ppr. But it has also run Xilinx ppr, so I'm > thinking it involves the work directory and "cleanup project files" too. > Perhaps if I ppr using the verilog file and then switch to the vhdl file > it works fine until I "cleanup project files" and the fails from that > point on? Anyway, the verilog code: > > always @ (CurrentState or count or rxstatus or rxelecidle or rx_locked or > align_det or sync_det) > begin : SM_mux > count_en = 1'b0; > NextState = host_comreset; > linkup_r = 1'b0; > txcomstart_r =1'b0; > txcomtype_r = 1'b0; > txelecidle_r = 1'b1; > send_d10_2_r = 1'b0; > send_align_r = 1'b0; > rxreset = 1'b0; > case (CurrentState) > host_comreset : > begin > if (rx_locked) > begin > > > was replaced with the vhdl code: > SM_mux : PROCESS > BEGIN > > WAIT ON CurrentState, count, rxstatus, rxelecidle, > rx_locked, align_det, sync_det; > > count_en <= '0'; > NextState <= host_comreset; > linkup_r <= '0'; > txcomstart_r <= '0'; > txcomtype_r <= '0'; > txelecidle_r <= '1'; > send_d10_2_r <= '0'; > send_align_r <= '0'; > V2V_rxreset <= '0'; > > CASE CurrentState IS > WHEN (X"0") => -- state 0 = host_comreset > > IF (rx_locked = '1') THEN > > and the vhdl error from Xilinx ppr points to the line with "SM_mux : > PROCESS " and says: > "Bad condition in wait statement, or only one clock per process." > > I'd be grateful if someone could help me out. > > Thanks > > Dan > >Article: 129803
You should send the link to Xilinx. Sometimes companies will have a gallery of devices that have used thier products. Having a device with an interesting story like coming form the black market and used in developing rusian spy technology, is just the thing marketing guys like to have to fill time and showusefulness of the devices. If my friend still worked for Xilinx, I would send the link to her. "Antti" <Antti.Lukats@googlemail.com> wrote in message news:efddea6a-a27c-4571-94a0-e12b829bce3f@n36g2000hse.googlegroups.com... > Hi > > some things are cute to trash, so if anyone cares for an item that > could have its honor place in "FPGA museum", here it is: > > http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&rd=1&item=190204160335 > > A Xilinx XC3030 based device manufactured by GRU (== russian CIA). > > I found it in the cellar. > And no, I did not get it directly from the source ;) > > AnttiArticle: 129804
1. In verilog, for continuous assignment, the assignee must be scalar
or vector net; for procedure assignment, the assignee cannot be scalar
or vector net; then for procedure continuous assignment, the assignee
can only be scalar or vector of registers. This is very confusing. I
can't quite see the logic behind such language design.
2. multiple event triggered always block updating same register
causing race condition or undefined behavior. e.g.
always @(posedge clock)
a = 1'b1;
always @(reset)
a = 1'b0;
If both reset turns high and clock turns high at the same time, what's
the result? I see code like this in text books which confuses me.
3. my understanding is that always statements is similar to
initial
forever statements
other than the practical reason always is preferred for looping
statements, any catch I don't see?
Thanks a lot!
Fei
Article: 129805"jtw" <wrightjt @hotmail.invalid> wrote in message news:8bpzj.14675$0o7.7677@newssvr13.news.prodigy.net... > You might want to also crosspost to comp.arch.fpga. > > > "jtw" <wrightjt @hotmail.invalid> wrote in message > news:L9pzj.14674$0o7.10494@newssvr13.news.prodigy.net... >> It's probably been over 20 years since I've used Aplus--was it 1984, or 1985? >> >> If you can post a snippet of the code, perhaps someone can translate? >> >> JTW >> >> "CTSportPilot" <girmann@gmail.com> wrote in message >> news:af888fdd-386e-492b-89ee-568bf48e5ea2@e25g2000prg.googlegroups.com... >>>I came across an ADF (Altera Desgn Format) file from an Altera EPLD. >>> Does anyone out there know of a syntax primer on this dead HDL >>> format? For those playing at home, this is an HDL from Altera that >>> came with the A+PLUS software. Yes, I can convert it to more modern >>> formats, but first I need to understand it. >>> >>> TIA! >> >> > > If you only want to use ADF files in Quartus, here is description of the whole conversion procedure (that involves MaxPlus-II too) http://www.altera.com/support/kdb/solutions/rd02012007_34.html For total re-write, I've got no idea :-( regards DejanArticle: 129806
austin <austin@xilinx.com> wrote: >Frai, > >There are many who claim "oh, this is easy..." > >However, back in the Virtex II Pro days, we issued a challenge, and more >than 7 universities and research groups accepted the challenge. > >We provided a 2vp7 pcb with usb port, and pins for access to power, that >had the key battery installed (300 mA lithiumm coin cell), and the part >was programmed with a 3DES encrypted bitstream. > >All 7 challengers gave up. Their basic conclusion was all the things >they thought would work, differential power attack, spoofing by power >glitches, attack with freeze spray, etc. FAILED. The word is there are companies that specialise in cracking these sort of security features. You'll have to bring a big amount of cash though. I'm not at all impressed by claiming the NSA or several universities couldn't crack it. Nice sales pitch, but I'm not buying it :-) The really clever people work where the money is and that is usually not in a government job. -- Programmeren in Almere? E-mail naar nico@nctdevpuntnl (punt=.)Article: 129807
>> What did the chips & software cost at the time..? >:) nothing / as not in shops... >pretty much ALL electronic components sales at that time was black- >market only. >And almost all of them was stolen from the military fabs. >There was very little in the official shops, the real component market >was openly-hidden somewhere close by in big cities Moscow/St. >Petersburg. In other places there was possible some "guy" coming each >few weeks with "stuff" so you could "pre-order" things from him. Or >you could go yourself to the cities where the fabs where and deal >there yourself. Funny times. >But when you ask the prices, actually I do recall the pricing, think >not much >different than now XC2064 around 15 USD I think. I recall it because >in one design >I used 13 GAL's what was not much more then price of cheapest Xilinx >chip >and the GAL's where around 1 USD I was mostly curious on the western market prices for the XC3030 + software. Not the russian one, which for obvious reasons was not so straightforward as the western one :) Though the history of getting a XC3030 in the 1980s russia is interesting ;)Article: 129808
Nico, Universities often crack crypto systems. They are usually the first to do so. DPA, and other techniques have all been pioneered at schools. I went out, and solicited bids for various "cracking" jobs. Unfortunately, no one took any of them. All I received was "no bid." There are reputable reverse engineering firms, but they are not stupid, they will not agree to do work for which they will not be paid. They had to deliver something in order to get paid. No bid. Could a nation-state decide to go and reverse engineer something? Sure, and that falls into the "infinite resource" attacker category. They might not succeed, but I am sure they would try their best. Thankfully, in the commercial segment, I don't have to worry about that level of attack. That is the level of attack the NSA is worrying about. And they said: "use Xilinx." AustinArticle: 129809
This question is better to ask on comp.lang.verilog. 1. Yep, very confusing. Thus why with System Verilog, you have new rules that don't care about where and what is assigned. type "logic" can be assigned in both flows. 2. That is the point of text book examples. It is supposed to be confusing. It is an example of what not to do. there are better ways to code this and know exactly what the result would be. In this case if reset changed value at the same time that clock had a posedge the final result would depend on the order that the TOOL executed the blocks. There is no defined garantee of which value would be written. 3. Logically the initial forever and always blocks appear to be similar. But you would be hard pressed to find a synthesis tool that will turn a initial forever construct into logic gates. For emulation there are some synthesis tools that can map an initial forever block to gates. Another gotcha is when is the block evaluated. The simulator must schedule events to happen. Based on the LRM and the tool nvendors interpretation of the LRM the order I which the initial blocks are evaluated and the always blocks are evaluated will change the behavior of the simulation. "Fei Liu" <fei.liu@gmail.com> wrote in message news:eea21b3c-f8f8-4ee3-b138-c900f4faed82@s19g2000prg.googlegroups.com... > 1. In verilog, for continuous assignment, the assignee must be scalar > or vector net; for procedure assignment, the assignee cannot be scalar > or vector net; then for procedure continuous assignment, the assignee > can only be scalar or vector of registers. This is very confusing. I > can't quite see the logic behind such language design. > > 2. multiple event triggered always block updating same register > causing race condition or undefined behavior. e.g. > > always @(posedge clock) > a = 1'b1; > always @(reset) > a = 1'b0; > If both reset turns high and clock turns high at the same time, what's > the result? I see code like this in text books which confuses me. > > 3. my understanding is that always statements is similar to > initial > forever statements > > other than the practical reason always is preferred for looping > statements, any catch I don't see? > > Thanks a lot! > > FeiArticle: 129810
> 2. That is the point of text book examples. It is supposed to be > confusing. It is an example of what not to do. there are better ways to code > this and know exactly what the result would be. In this case if reset > changed value at the same time that clock had a posedge the final result > would depend on the order that the TOOL executed the blocks. There is no > defined garantee of which value would be written. Yeah, my point is text book authors should avoid having such kind of code in examples here and there, except to illustrate this is a bad coding practice. But what I see is that authors feel it's acceptable to write code like this. It annoys me.Article: 129811
On Mar 5, 7:57 pm, Fei Liu <fei....@gmail.com> wrote:
> > 2. That is the point of text book examples. It is supposed to be
> > confusing. It is an example of what not to do. there are better ways to code
> > this and know exactly what the result would be. In this case if reset
> > changed value at the same time that clock had a posedge the final result
> > would depend on the order that the TOOL executed the blocks. There is no
> > defined garantee of which value would be written.
>
> Yeah, my point is text book authors should avoid having such kind of
> code in examples here and there, except to illustrate this is a bad
> coding practice. But what I see is that authors feel it's acceptable
> to write code like this. It annoys me.
Icarus verilog interprets the posedge as "higher priorty" than the
reset changing (always@reset implies change, not just high or low).
The real question is how does the design compiler interpret this? I
think that rather than writing ambiguous behavioral code for the
design compiler to interpret as the book suggests, write it the
"normal way" as you would want it to synthesize:
always @ (posedge clock or negedge reset)
if you want an active low asynchronous reset.
The academics just want you to understand all corners of the language
I guess.
here's my test code:
//test.v
module counter(out, clk, reset);
parameter WIDTH = 8;
output [WIDTH-1 : 0] out;
input clk, reset;
reg [WIDTH-1 : 0] out;
wire clk, reset;
always @reset
out = 0;
always @(posedge clk)
out = 1;
endmodule // counter
//test_test.v
module test;
/* Make a reset that pulses once. */
reg reset = 0;
initial begin
# 5 reset = 1;
# 10 reset = 0;
# 5 reset = 1;
# 5 reset = 0;
# 100 $finish;
end
/* Make a regular pulsing clock. */
reg clk = 0;
always #5 clk = !clk;
wire [7:0] value;
counter c1 (value, clk, reset);
initial
$monitor("At time %t, reset %h value = %h (%0d)",
$time, reset, value, value);
endmodule // test
and run:
iverilog test.v test_test.v -o test & ./test
Article: 129812On 2008-03-05, Antti <Antti.Lukats@googlemail.com> wrote: > What I have heard the "thumb estimate" to read out ANY FLASH > based microcontrollers protected code is about 1000 USD. > Reading back a protected ATmega8 has been as cheap as 800RMB (112USD) > (no I have not done that, I just know the work being quoted at that > price) A bit off topic, but I have found the following blog quite an interesting read regarding the security of various products: http://www.flylogic.net/blog/ They also have very nice photos on it :) /AndreasArticle: 129813
Hi all, thank you for these notions. @ Allan : thanks for this link.Article: 129814
In altera and xilinx how to know that a design works at what frequency. If anyone explains me this one clearly means that will be very much of helpful. I have a design developed long before now i want the same desin to work for the double frequency at what it was working before. So for this what i have to do. can we synthesize, for and configuration statements in VHDLArticle: 129815
On Mar 5, 4:32=A0pm, maverick <sheikh.m.far...@gmail.com> wrote: > Hi, > I have a design for a custom made board with Spartan 3 xc3s1000 on it. > There is a SATA controller on the same board. Since this SATA > controller uses PCI interface to communicate to the outer world, I > have used opencores PCI bridge inside FPGA to communicate with SATA > controller. The synthesized design works fine however I do get some > initialization errors at startup. It seems more like a timing problem > to me. When analyzed critically, I observed that many of the timing > constraints are being ignored by the synthesis tool (ISE 7.1i and ISE > 9.2i). I have multiple clocks in my design and there are clock > crossing domains. I have marked those domaing and TIGed them in the > UCF. I am suspecting that the problem that I am facing is becuase of > these ignored timing constraints. The portion of the UCF file where > these timings contraints are written is pasted below. > =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 > INST "AD<0>" TNM =3D "PCI_AD"; > INST "AD<1>" TNM =3D "PCI_AD"; > INST "AD<2>" TNM =3D "PCI_AD"; > INST "AD<3>" TNM =3D "PCI_AD"; > INST "AD<4>" TNM =3D "PCI_AD"; > INST "AD<5>" TNM =3D "PCI_AD"; > INST "AD<6>" TNM =3D "PCI_AD"; > INST "AD<7>" TNM =3D "PCI_AD"; > INST "AD<8>" TNM =3D "PCI_AD"; > INST "AD<9>" TNM =3D "PCI_AD"; > INST "AD<10>" TNM =3D "PCI_AD"; > INST "AD<11>" TNM =3D "PCI_AD"; > INST "AD<12>" TNM =3D "PCI_AD"; > INST "AD<13>" TNM =3D "PCI_AD"; > INST "AD<14>" TNM =3D "PCI_AD"; > INST "AD<15>" TNM =3D "PCI_AD"; > INST "AD<16>" TNM =3D "PCI_AD"; > INST "AD<17>" TNM =3D "PCI_AD"; > INST "AD<18>" TNM =3D "PCI_AD"; > INST "AD<19>" TNM =3D "PCI_AD"; > INST "AD<20>" TNM =3D "PCI_AD"; > INST "AD<21>" TNM =3D "PCI_AD"; > INST "AD<22>" TNM =3D "PCI_AD"; > INST "AD<23>" TNM =3D "PCI_AD"; > INST "AD<24>" TNM =3D "PCI_AD"; > INST "AD<25>" TNM =3D "PCI_AD"; > INST "AD<26>" TNM =3D "PCI_AD"; > INST "AD<27>" TNM =3D "PCI_AD"; > INST "AD<28>" TNM =3D "PCI_AD"; > INST "AD<29>" TNM =3D "PCI_AD"; > INST "AD<30>" TNM =3D "PCI_AD"; > INST "AD<31>" TNM =3D "PCI_AD"; > > TIMEGRP "PCI_AD" OFFSET =3D IN 7 ns BEFORE "CLK_66"; > TIMEGRP "PCI_AD" OFFSET =3D OUT 11 ns AFTER "CLK_66"; > > INST "CBE<0>" TNM =3D "PCI_CBE"; > INST "CBE<1>" TNM =3D "PCI_CBE"; > INST "CBE<2>" TNM =3D "PCI_CBE"; > INST "CBE<3>" TNM =3D "PCI_CBE"; > > TIMEGRP "PCI_CBE" OFFSET =3D IN 7 ns BEFORE "CLK_66"; > TIMEGRP "PCI_CBE" OFFSET =3D OUT 11 ns AFTER "CLK_66"; > > NET "DEVSEL" OFFSET =3D IN 7 ns BEFORE "CLK_66"; > NET "DEVSEL" OFFSET =3D OUT 11 ns AFTER "CLK_66"; > > NET "FRAME" OFFSET =3D IN 7 ns BEFORE "CLK_66"; > NET "FRAME" OFFSET =3D OUT 11 ns AFTER "CLK_66"; > > NET "SATA_GNT" OFFSET =3D IN 10 ns BEFORE "CLK_66"; > > NET "IRDY" OFFSET =3D IN 7 ns BEFORE "CLK_66"; > NET "IRDY" OFFSET =3D OUT 11 ns AFTER "CLK_66"; > > NET "PAR" OFFSET =3D IN 7 ns BEFORE "CLK_66"; > NET "PAR" OFFSET =3D OUT 11 ns AFTER "CLK_66"; > > NET "PERR" OFFSET =3D IN 7 ns BEFORE "CLK_66"; > NET "PERR" OFFSET =3D OUT 11 ns AFTER "CLK_66"; > > NET "SATA_REQ" OFFSET =3D OUT 12 ns AFTER "CLK_66"; > > NET "SERR" OFFSET =3D OUT 11 ns AFTER "CLK_66"; > > NET "STOP" OFFSET =3D IN 7 ns BEFORE "CLK_66"; > NET "STOP" OFFSET =3D OUT 11 ns AFTER "CLK_66"; > > NET "TRDY" OFFSET =3D IN 7 ns BEFORE "CLK_66"; > NET "TRDY" OFFSET =3D OUT 11 ns AFTER "CLK_66"; > > NET "SATA_IDSEL" OFFSET =3D IN 7 ns BEFORE "CLK_66"; > > ##########################################################################= #=AD########################### > > NET "CLK_125" TNM_NET =3D "CLK_125"; > TIMESPEC "TS_CLK_125" =3D PERIOD "CLK_125" 8 ns HIGH 50 %; > NET "CLK_66" TNM_NET =3D "CLK_66"; > TIMESPEC "TS_CLK_66" =3D PERIOD "CLK_66" 14 ns HIGH 50 %; > NET "uc_clk" TNM_NET =3D "uc_clk"; > TIMESPEC "TS_uc_clk" =3D PERIOD "uc_clk" 1000 ns HIGH 50 %; > > NET "tx_clk" TNM_NET =3D "tx_clk"; > TIMESPEC "TS_tx_clk" =3D PERIOD "tx_clk" 40 ns HIGH 50 %; > > NET "rx_clk" TNM_NET =3D "rx_clk"; > TIMESPEC "TS_rx_clk" =3D PERIOD "rx_clk" 40 ns HIGH 50 %; > > #################### > # =A0 =A0 =A0 Domains Created > #################### > # domain_clk_33 > # domain_clk_uc > # domain_clk_adc > # domain_clk_66 > # domain_emac_clk_rx > # domain_emac_clk_tx > > NET "uc_clk" TNM_NET =3D "domain_clk_uc"; > NET "CLK_66" TNM_NET =3D "domain_clk_66"; > NET "CLK_33" TNM_NET =3D "domain_clk_33"; > #NET "CLK_125" TNM_NET=3D "domain_clk_125" > NET "CLK_ADC" TNM_NET =3D "domain_clk_adc"; > NET "tx_clk" TNM_NET =3D "domain_clk_tx"; > NET "rx_clk" TNM_NET =3D "domain_clk_rx"; > > TIMESPEC "TS_clk_uC_to_clk_66" =3D FROM "domain_clk_uc" TO > "domain_clk_66" =A0TIG; > TIMESPEC "TS_clk_uC_to_clk_33" =3D FROM "domain_clk_uc" TO > "domain_clk_33" =A0TIG; > #TIMESPEC "TS_clk_uC_to_clk_125" =3D =A0FROM "domain_clk_uc" TO > "domain_clk_125" TIG > TIMESPEC "TS_clk_uC_to_clk_adc" =3D FROM "domain_clk_uc" TO > "domain_clk_adc" =A0TIG; > TIMESPEC "TS_clk_uC_to_clk_tx" =3D FROM "domain_clk_uc" TO > "domain_clk_tx" =A0TIG; > TIMESPEC "TS_clk_uC_to_clk_rx" =3D FROM "domain_clk_uc" TO > "domain_clk_rx" =A0TIG; > > TIMESPEC "TS_clk_66_to_clk_uc" =3D FROM "domain_clk_66" TO > "domain_clk_uc" =A0TIG; > TIMESPEC "TS_clk_66_to_clk_33" =3D FROM "domain_clk_66" TO > "domain_clk_33" =A0TIG; > #TIMESPEC "TS_clk_66_to_clk_125" =3D =A0FROM "domain_clk_66" TO > "domain_clk_125" TIG > TIMESPEC "TS_clk_66_to_clk_adc" =3D FROM "domain_clk_66" TO > "domain_clk_adc" =A0TIG; > TIMESPEC "TS_clk_66_to_clk_tx" =3D FROM "domain_clk_66" TO > "domain_clk_tx" =A0TIG; > TIMESPEC "TS_clk_66_to_clk_rx" =3D FROM "domain_clk_66" TO > "domain_clk_rx" =A0TIG; > > TIMESPEC "TS_clk_33_to_clk_uc" =3D FROM "domain_clk_33" TO > "domain_clk_uc" =A0TIG; > TIMESPEC "TS_clk_33_to_clk_66" =3D FROM "domain_clk_33" TO > "domain_clk_66" =A0TIG; > #TIMESPEC "TS_clk_33_to_clk_125" =3D =A0FROM "domain_clk_33" TO > "domain_clk_125" TIG > TIMESPEC "TS_clk_33_to_clk_adc" =3D FROM "domain_clk_33" TO > "domain_clk_adc" =A0TIG; > TIMESPEC "TS_clk_33_to_clk_tx" =3D FROM "domain_clk_33" TO > "domain_clk_tx" =A0TIG; > TIMESPEC "TS_clk_33_to_clk_rx" =3D FROM "domain_clk_33" TO > "domain_clk_rx" =A0TIG; > > TIMESPEC "TS_clk_adc_to_clk_uc" =3D FROM "domain_clk_adc" TO > "domain_clk_uc" =A0TIG; > TIMESPEC "TS_clk_adc_to_clk_33" =3D FROM "domain_clk_adc" TO > "domain_clk_33" =A0TIG; > #TIMESPEC "TS_clk_adc_to_clk_125"=3D =A0FROM "domain_clk_adc" TO > "domain_clk_125" TIG > TIMESPEC "TS_clk_adc_to_clk_66" =3D FROM "domain_clk_adc" TO > "domain_clk_66" =A0TIG; > TIMESPEC "TS_clk_adc_to_clk_tx" =3D FROM "domain_clk_adc" TO > "domain_clk_tx" =A0TIG; > TIMESPEC "TS_clk_adc_to_clk_rx" =3D FROM "domain_clk_adc" TO > "domain_clk_rx" =A0TIG; > > TIMESPEC "TS_clk_tx_to_clk_uc" =3D FROM "domain_clk_tx" TO > "domain_clk_uc" =A0TIG; > TIMESPEC "TS_clk_tx_to_clk_33" =3D FROM "domain_clk_tx" TO > "domain_clk_33" =A0TIG; > #TIMESPEC "TS_clk_tx_to_clk_125" =3D FROM "domain_clk_tx" TO > "domain_clk_125" TIG > TIMESPEC "TS_clk_tx_to_clk_adc" =3D FROM "domain_clk_tx" TO > "domain_clk_adc" =A0TIG; > TIMESPEC "TS_clk_tx_to_clk_66" =3D FROM "domain_clk_tx" TO > "domain_clk_66" =A0TIG; > TIMESPEC "TS_clk_tx_to_clk_rx" =3D FROM "domain_clk_tx" TO > "domain_clk_rx" =A0TIG; > > TIMESPEC "TS_clk_rx_to_clk_uc" =3D FROM "domain_clk_rx" TO > "domain_clk_uc" =A0TIG; > TIMESPEC "TS_clk_rx_to_clk_33" =3D FROM "domain_clk_rx" TO > "domain_clk_33" =A0TIG; > #TIMESPEC "TS_clk_rx_to_clk_125" =3D FROM "domain_clk_rx" TO > "domain_clk_125" TIG > TIMESPEC "TS_clk_rx_to_clk_adc" =3D FROM "domain_clk_rx" TO > "domain_clk_adc" =A0TIG; > TIMESPEC "TS_clk_rx_to_clk_tx" =3D FROM "domain_clk_rx" TO > "domain_clk_tx" =A0TIG; > TIMESPEC "TS_clk_rx_to_clk_66" =3D FROM "domain_clk_rx" TO > "domain_clk_66" =A0TIG; > > NET "CLK_33_OBUF" TNM_NET =3D "CLK_33_OBUF"; > TIMESPEC "TS_CLK_33_OBUF" =3D PERIOD "CLK_33_OBUF" 30.03 ns HIGH 50 %; > > TIMESPEC "TS_F2F" =3D FROM "FFS" TO "FFS" 14 ns; > > // > *********************************************************************=3D= =3D=3D=3D=3D=3D=AD=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D// > This is what I get from ISE 9.2 i during implementation process. > > //////////////////////////////////////////////////////////////////////////= /=AD//////////////////////////////////////////////////////////////// > > WARNING:Timing:3223 - Timing constraint PATH "TS_U_TO_D_path" TIG; > ignored during timing analysis. > WARNING:Timing:3223 - Timing constraint PATH > "TS_clk_uC_to_clk_33_path" TIG; ignored during timing analysis. > WARNING:Timing:3223 - Timing constraint PATH > "TS_clk_uC_to_clk_adc_path" TIG; ignored during timing analysis. > WARNING:Timing:3223 - Timing constraint PATH > "TS_clk_uC_to_clk_tx_path" TIG; ignored during timing analysis. > WARNING:Timing:3223 - Timing constraint PATH > "TS_clk_uC_to_clk_rx_path" TIG; ignored during timing analysis. > WARNING:Timing:3223 - Timing constraint PATH > "TS_clk_66_to_clk_adc_path" TIG; ignored during timing analysis. > WARNING:Timing:3223 - Timing constraint PATH > "TS_clk_33_to_clk_uc_path" TIG; ignored during timing analysis. > WARNING:Timing:3223 - Timing constraint PATH > "TS_clk_33_to_clk_66_path" TIG; ignored during timing analysis. > WARNING:Timing:3223 - Timing constraint PATH > "TS_clk_33_to_clk_adc_path" TIG; ignored during timing analysis. > WARNING:Timing:3223 - Timing constraint PATH > "TS_clk_33_to_clk_tx_path" TIG; ignored during timing analysis. > WARNING:Timing:3223 - Timing constraint PATH > "TS_clk_33_to_clk_rx_path" TIG; ignored during timing analysis. > WARNING:Timing:3223 - Timing constraint PATH > "TS_clk_adc_to_clk_uc_path" TIG; ignored during timing analysis. > WARNING:Timing:3223 - Timing constraint PATH > "TS_clk_adc_to_clk_33_path" TIG; ignored during timing analysis. > WARNING:Timing:3223 - Timing constraint PATH > "TS_clk_adc_to_clk_66_path" TIG; ignored during timing analysis. > WARNING:Timing:3223 - Timing constraint PATH > "TS_clk_adc_to_clk_tx_path" TIG; ignored during timing analysis. > WARNING:Timing:3223 - Timing constraint PATH > "TS_clk_adc_to_clk_rx_path" TIG; ignored during timing analysis. > WARNING:Timing:3223 - Timing constraint PATH > "TS_clk_tx_to_clk_uc_path" TIG; ignored during timing analysis. > WARNING:Timing:3223 - Timing constraint PATH > "TS_clk_tx_to_clk_33_path" TIG; ignored during timing analysis. > WARNING:Timing:3223 - Timing constraint PATH > "TS_clk_tx_to_clk_adc_path" TIG; ignored during timing analysis. > WARNING:Timing:3223 - Timing constraint PATH > "TS_clk_tx_to_clk_rx_path" TIG; ignored during timing analysis. > WARNING:Timing:3223 - Timing constraint PATH > "TS_clk_rx_to_clk_uc_path" TIG; ignored during timing analysis. > WARNING:Timing:3223 - Timing constraint PATH > "TS_clk_rx_to_clk_33_path" TIG; ignored during timing analysis. > WARNING:Timing:3223 - Timing constraint PATH > "TS_clk_rx_to_clk_adc_path" TIG; ignored during timing analysis. > WARNING:Timing:3223 - Timing constraint PATH > "TS_clk_rx_to_clk_tx_path" TIG; ignored during timing analysis. > WARNING:Timing:3175 - CLK_66 does not clock data from STOP > WARNING:Timing:3225 - Timing constraint COMP "STOP" OFFSET =3D IN 7 ns > BEFORE COMP "CLK_66"; ignored during timing > =A0 =A0analysis > WARNING:Timing:3175 - CLK_66 does not clock data to STOP > WARNING:Timing:3225 - Timing constraint COMP "STOP" OFFSET =3D OUT 11 ns > AFTER COMP "CLK_66"; ignored during timing > =A0 =A0analysis > WARNING:Timing:3175 - CLK_66 does not clock data from DEVSEL > WARNING:Timing:3225 - Timing constraint COMP "DEVSEL" OFFSET =3D IN 7 ns > BEFORE COMP "CLK_66"; ignored during timing > =A0 =A0analysis > WARNING:Timing:3175 - CLK_66 does not clock data to DEVSEL > WARNING:Timing:3225 - Timing constraint COMP "DEVSEL" OFFSET =3D OUT 11 > ns AFTER COMP "CLK_66"; ignored during timing > =A0 =A0analysis > WARNING:Timing:3175 - CLK_66 does not clock data to IRDY > WARNING:Timing:3225 - Timing constraint COMP "IRDY" OFFSET =3D OUT 11 ns > AFTER COMP "CLK_66"; ignored during timing > =A0 =A0analysis > WARNING:Timing:3175 - CLK_66 does not clock data to TRDY > WARNING:Timing:3225 - Timing constraint COMP "TRDY" OFFSET =3D OUT 11 ns > AFTER COMP "CLK_66"; ignored during timing > =A0 =A0analysis > WARNING:Timing:3175 - CLK_66 does not clock data from PERR > WARNING:Timing:3225 - Timing constraint COMP "PERR" OFFSET =3D IN 7 ns > BEFORE COMP "CLK_66"; ignored during timing > =A0 =A0analysis > WARNING:Timing:3175 - CLK_66 does not clock data to PERR > WARNING:Timing:3225 - Timing constraint COMP "PERR" OFFSET =3D OUT 11 ns > AFTER COMP "CLK_66"; ignored during timing > =A0 =A0analysis > WARNING:Timing:3175 - CLK_66 does not clock data from PAR > WARNING:Timing:3225 - Timing constraint COMP "PAR" OFFSET =3D IN 7 ns > BEFORE COMP "CLK_66"; ignored during timing analysis > WARNING:Timing:3175 - CLK_66 does not clock data to PAR > WARNING:Timing:3225 - Timing constraint COMP "PAR" OFFSET =3D OUT 11 ns > AFTER COMP "CLK_66"; ignored during timing > =A0 =A0analysis > WARNING:Timing:3175 - CLK_66 does not clock data to FRAME > WARNING:Timing:3225 - Timing constraint COMP "FRAME" OFFSET =3D OUT 11 > ns AFTER COMP "CLK_66"; ignored during timing > =A0 =A0analysis > WARNING:Timing:3175 - CLK_66 does not clock data to SERR > WARNING:Timing:3225 - Timing constraint COMP "SERR" OFFSET =3D OUT 11 ns > AFTER COMP "CLK_66"; ignored during timing > =A0 =A0analysis > WARNING:Timing:3175 - CLK_66 does not clock data to SATA_REQ > WARNING:Timing:3225 - Timing constraint COMP "SATA_REQ" OFFSET =3D OUT > 12 ns AFTER COMP "CLK_66"; ignored during timing > =A0 =A0analysis > WARNING:Timing:3175 - CLK_66 does not clock data from SATA_IDSEL > WARNING:Timing:3225 - Timing constraint COMP "SATA_IDSEL" OFFSET =3D IN > 7 ns BEFORE COMP "CLK_66"; ignored during timing > =A0 =A0analysis > WARNING:Timing:3175 - CLK_66 does not clock data from SATA_GNT > WARNING:Timing:3225 - Timing constraint COMP "SATA_GNT" OFFSET =3D IN 10 > ns BEFORE COMP "CLK_66"; ignored during timing > =A0 =A0analysis > WARNING:Timing:3224 - The clock CLK_66 associated with TIMEGRP > "PCI_AD" OFFSET =3D IN 7 ns BEFORE COMP "CLK_66"; does not > =A0 =A0clock any registered input components. > WARNING:Timing:3225 - Timing constraint TIMEGRP "PCI_AD" OFFSET =3D IN 7 > ns BEFORE COMP "CLK_66"; ignored during timing > =A0 =A0analysis > WARNING:Timing:3224 - The clock CLK_66 associated with TIMEGRP > "PCI_AD" OFFSET =3D OUT 11 ns AFTER COMP "CLK_66"; does not > =A0 =A0clock any registered output components. > WARNING:Timing:3225 - Timing constraint TIMEGRP "PCI_AD" OFFSET =3D OUT > 11 ns AFTER COMP "CLK_66"; ignored during timing > =A0 =A0analysis > WARNING:Timing:3224 - The clock CLK_66 associated with TIMEGRP > "PCI_CBE" OFFSET =3D OUT 11 ns AFTER COMP "CLK_66"; does > =A0 =A0not clock any registered output components. > WARNING:Timing:3225 - Timing constraint TIMEGRP "PCI_CBE" OFFSET =3D OUT > 11 ns AFTER COMP "CLK_66"; ignored during timing > =A0 =A0analysis > //////////////////////////////////////////////////////////////////////////= /=AD/////////////////////////////////////////////////////////////// > > The question is why the tool is ignoring almost all timing > constraints? > My second question is, OFFSET IN OFFSET OUT contraints are used with > respect to clock which is a global clock and locked to some GCLK pin. > These constraints cannot be applied with respect to clocks which are > genreated inside the FPGA. If I want to run the PCI on 33 MHz, I will > get a divided by 2 version of the 66 MHz clock which is an external > clock in my case. In that case, how would I apply the OFFSET IN OFFSET > out constraints with respect to teh 33 MHz clock? I tried to use FROM > TO constraints, is that OK? for example > > INST "FRAME" TNM =3D "PCI_FRAME"; > TIMESPEC "TS_PCI_FRAME0" =3D FROM "PCI_FRAME" TO "PADS" 11 ns; > TIMESPEC "TS_PCI_FRAME1" =3D FROM "PADS" TO "PCI_FRAME" 7 ns; > > Thanks in advance for reading such a long posting. I hope people out > there have answers to my queries. > > Regards > Farhan //--------------------------------------------------------------------------= --// Anyone out there to help me out here. FarhanArticle: 129816
On Mar 4, 12:10 pm, FPGA <FPGA.unkn...@gmail.com> wrote: > On Mar 4, 10:45 am, Tricky <Trickyh...@gmail.com> wrote: > > > > > On Mar 4, 3:23 pm, FPGA <FPGA.unkn...@gmail.com> wrote: > > > > On Mar 4, 9:12 am, Tricky <Trickyh...@gmail.com> wrote: > > > > > On Mar 4, 2:00 pm, FPGA <FPGA.unkn...@gmail.com> wrote: > > > > > > On Mar 4, 4:26 am, Tricky <Trickyh...@gmail.com> wrote: > > > > > > > On Mar 3, 9:15 pm, FPGA <FPGA.unkn...@gmail.com> wrote: > > > > > > > > I have written a process to generate random numbers using UNIFORM. I > > > > > > > was trying to check the results using "rand" in matlab. How do i > > > > > > > initialise the seed values of both these functions to the same value. > > > > > > > I see that the random numbers generated by UNIFORM are different > > > > > > > compared to rand when the seed values are left uninitialised. > > > > > > > What do I need to change so that I get same output from both programs. > > > > > > > > Thanks > > > > > > > Uninitilised positives (the seeds in this case) will take a value of 1 > > > > > > when they are put into the uniform function. Unitialised types when > > > > > > used will take type'low as their value > > > > > > > positive'low = 1 > > > > > > std_logic'low = 'u' > > > > > > etc. > > > > > > > so both of your first calls to uniform are seeding it with two 1s. > > > > > > > I dont know how the seeding works in matlab. It may not even use > > > > > > positives, but the entire integer range. it is common in C to seed the > > > > > > random number generator with the system time. Does matlab do something > > > > > > similar? The C random function only has 1 seed, whereas uniform takes > > > > > > 2. > > > > > > I am not sure how the rand function in MATLAB works. I tried to search > > > > > if the code of the function was described anywhere but couldnt find. > > > > > I dont know if we can get MATLAB to generate results as UNIFORM does. > > > > > As you said, uniform has 2 seeds while rand has 1. > > > > > If anyone has an idea on how this can be done, please post your > > > > > comment. > > > > > Why not generate a file containing all the stimulus for the vhdl and > > > > matlab model in one or the other, instead of trying to recreate the > > > > random sequence?- Hide quoted text - > > > > > - Show quoted text - > > > > The goal is to check that the VHDL code generates results similar to > > > MATLAB . I have written the outputs of both in seperate text files. I > > > am not able to initialise the rand function to generate results > > > similar to MATLAB and vice versa. Called MATLAB today to get some more > > > information on how they have developed the rand function. They said > > > that this information is not available to the public. > > > I think one of the ways to do this would be, generating a pdf function > > > for both cases and showing that their random distriution is similar. > > > > If any of you have other ideas please post them. > > > In that case, why are you even trying to do this? generate a file from > > matlab that is used as the stimulus for the VHDL testbench. Then you > > do not need to use the uniform function at all, and then you are > > testing that the results match.- Hide quoted text - > > > - Show quoted text - > > I have to use the UNFORM function to check if it behaves in sync with > MATLAB. I have given up on getting the same results in matlab as in > VHDL. I am just trying to get a pdf plot of both results. No idea on > how to do this yet. Sounds like you have an ill-posed question here. Mathworks won't tell you how it got it's pseudo-random stream...call it rand(i), where rand(0) is the seed.(In fact, you don't even know if there is a single seed or any seed for that matter!) You have created a pseudo-random stream fpga_rand(i), where the seed is fpga_rand(0). You are going to have to be satisfied with using statistical tests to verify that your function fpga_rand passes as many of the tests as you need, or at least as many as the matlab rand function passes. Look up http://en.wikipedia.org/wiki/Diehard_tests alanArticle: 129817
"Antti" <Antti.Lukats@googlemail.com> wrote in message news:0accf01e-f995-494a-a718-fc545059b279@e60g2000hsh.googlegroups.com... > > pretty much ALL electronic components sales at that time was black- > market only. > And almost all of them was stolen from the military fabs. > There was very little in the official shops, the real component market > was openly-hidden somewhere close by in big cities Moscow/St. > Petersburg. Antti, this is more or less true, but only from the point of view of an individual willing to do something at home at that time. If electronic design was your full-time job the situation would be quite different, and what was available to you depended on which industry your institution worked for and on some other factors including personal relationships of your bosses, etc... Foreign parts were usually purchased as temporary subs for future functional clones :) /MikhailArticle: 129818
"Dwayne Dilbeck" <ddilbeck@yahoo.com> wrote in message news:13su9aog65jr83@corp.supernews.com... > Having a device with an interesting story like coming form the black > market and used in developing rusian spy technology, is just the thing > marketing guys like to have to fill time and show usefulness of the > devices. With all due respect, this is all a pure speculation... Antti doesn't seem to know the real story behind this board... /MikhailArticle: 129819
Try changing this:
DSM_mux : PROCESS
> BEGIN
>
> WAIT ON CurrentState, count, rxstatus, rxelecidle,
> rx_locked, align_det, sync_det;
...
for this:
DSM_mux : PROCESS (CurrentState, count, rxstatus, rxelecidle,
rx_locked, align_det, sync_det)
BEGIN
count_en <= '0';
NextState <= host_comreset;
...
HTH
-P@
wayne Dilbeck wrote:
> You could have worse problems in store for you. Your verilog and vhdl code
> may not perform the way you think they will. You have only posted a subset
> of the code so I can't tell if the difference will bite you now or only in
> the future when you change your code.
>
> In your verilog code you are use blocking assignments. This means in the
> future any use of that reg will have the new value that was recently set. In
> the VHDL your code is assigning signals, signals do not get updated until
> the process finishes executing. Which means references to those signal
> names will use the old value for computations not the new value like the
> verilog code does. A general rule of thumb when converting between
> vhdl<->verilog blocking converts to variables and non-blockign converts to
> signals.
> This probably isn't an issue right now. You haven't gotten far enough into
> the process for these difference to show up. They wouldn't show up as an
> error message. They normally show up as 2-3 days of tearing you hair out
> trying to figure out why the code isn't working as expected.
>
> You can attempt to bypass your current error by using:
>
> SM_mux : process(CurrentState, count, rxstatus, rxelecidle,rx_locked,
> align_det, sync_det)
>
> and eliminating the "WAIT ON" line.
>
> it will still be equivalent, but the xilinx software may be getting confused
> on the "wait" statement and tring to infer flipflops or multiple clocks
> instead of pure combinational logice. Granted, this is a guess based on the
> code snippets. The full RTL could get you better answers. You also want to
> post on the comp.lang.vhdl and comp.lang.verilog news groups. You might get
> more feed back.
>
> "Dan K" <danielgkNOSPAM@visi.com> wrote in message
> news:QHEzj.6$1g.1@fe24.usenetserver.com...
>> I'm having a problem with a state machine written in verilog that I need
>> to get into vhdl. My simulation license only allows vhdl and I can't
>> afford one that will do both. The problems is worse because it simulates
>> just fine, but fails Xilinx ppr. But it has also run Xilinx ppr, so I'm
>> thinking it involves the work directory and "cleanup project files" too.
>> Perhaps if I ppr using the verilog file and then switch to the vhdl file
>> it works fine until I "cleanup project files" and the fails from that
>> point on? Anyway, the verilog code:
>>
>> always @ (CurrentState or count or rxstatus or rxelecidle or rx_locked or
>> align_det or sync_det)
>> begin : SM_mux
>> count_en = 1'b0;
>> NextState = host_comreset;
>> linkup_r = 1'b0;
>> txcomstart_r =1'b0;
>> txcomtype_r = 1'b0;
>> txelecidle_r = 1'b1;
>> send_d10_2_r = 1'b0;
>> send_align_r = 1'b0;
>> rxreset = 1'b0;
>> case (CurrentState)
>> host_comreset :
>> begin
>> if (rx_locked)
>> begin
>>
>>
>> was replaced with the vhdl code:
>> SM_mux : PROCESS
>> BEGIN
>>
>> WAIT ON CurrentState, count, rxstatus, rxelecidle,
>> rx_locked, align_det, sync_det;
>>
>> count_en <= '0';
>> NextState <= host_comreset;
>> linkup_r <= '0';
>> txcomstart_r <= '0';
>> txcomtype_r <= '0';
>> txelecidle_r <= '1';
>> send_d10_2_r <= '0';
>> send_align_r <= '0';
>> V2V_rxreset <= '0';
>>
>> CASE CurrentState IS
>> WHEN (X"0") => -- state 0 = host_comreset
>>
>> IF (rx_locked = '1') THEN
>>
>> and the vhdl error from Xilinx ppr points to the line with "SM_mux :
>> PROCESS " and says:
>> "Bad condition in wait statement, or only one clock per process."
>>
>> I'd be grateful if someone could help me out.
>>
>> Thanks
>>
>> Dan
>>
>>
>
>
Article: 129820On 6 Mrz., 07:00, "MM" <mb...@yahoo.com> wrote: > "Dwayne Dilbeck" <ddilb...@yahoo.com> wrote in message > > news:13su9aog65jr83@corp.supernews.com... > > > Having a device with an interesting story like coming form the black > > market and used in developing rusian spy technology, is just the thing > > marketing guys like to have to fill time and show usefulness of the > > devices. > > With all due respect, this is all a pure speculation... Antti doesn't seem > to know the real story behind this board... > > /Mikhail Mikhail, with all due respect, I do. AnttiArticle: 129821
On 6 Mrz., 06:58, "MM" <mb...@yahoo.com> wrote: > "Antti" <Antti.Luk...@googlemail.com> wrote in message > > news:0accf01e-f995-494a-a718-fc545059b279@e60g2000hsh.googlegroups.com... > > > > > pretty much ALL electronic components sales at that time was black- > > market only. > > And almost all of them was stolen from the military fabs. > > There was very little in the official shops, the real component market > > was openly-hidden somewhere close by in big cities Moscow/St. > > Petersburg. > > Antti, this is more or less true, but only from the point of view of an > individual willing to do something at home at that time. If electronic > design was your full-time job the situation would be quite different, and > what was available to you depended on which industry your institution worked > for and on some other factors including personal relationships of your > bosses, etc... Foreign parts were usually purchased as temporary subs for > future functional clones :) > > /Mikhail Sure there are many points of view a always. Sure the "zhirpotreb" (consumer) versions of the electronics components was possible to buy via official channels. But even so there was quite often a need for special "salesman" that all could trink lots of vodka and use personal contacts to "accelerate". Those salesman did travel the fabs and arranged that some orders did get process more quickly. But not all components had non-military versions with prefix "K", and those it was more a problem to get them for consumer products. Russian did of clone lots of western components, but sometimes they had very bad yield, at least with components with K prefix. Like the i8275 (Russian version) was hard to get, and had maybe 10% yield of what was sold openly. Original i8275 was also obtainable but for rather high price. I started with electronic as hobby in 1979 and I had many friends who all wanted to have access to the LATEST and GREATEST of that times, and it usually did take lots of seeking to get hand on them. Not much on normal sales channels. Eh folks its not that different now either, the latest and greatest parts are "early access", under NDA, special customer only. AnttiArticle: 129822
Hi, The maximum clock frequency, critical Path etc. are availabe in the static timing report generated by your implementation tool. Approximations can also be found in the synthesis report (at least in XST). These values might be worsened by the actual Place & Route. If your old design is now targeted for an actual fpga technology (e.g. migrationg from Spartan2 to Spartan3) you can expect a good increase in the max. possible clock frequency. Otherwise, if you want to use the same old hardware but double your clock frequency, you have to check the actuaal speed first (static timing report) and, if neccessary, think about redesigning the parts that are identified by the critical path informations. One possible approach is pipelining, if applicable. But sometimes a different coding of the combinatorical part can also be helpful. For loops and for generate are synthesizable. Configurations are for simulation only. Have a nice synthesis Eilert kiransr.ckm@gmail.com schrieb: > In altera and xilinx how to know that a design works at what > frequency. If anyone explains me this one clearly means that will be > very much of helpful. > > I have a design developed long before now i want the same desin to > work for the double frequency at what it was working before. So for > this what i have to do. > > can we synthesize, for and configuration statements in VHDLArticle: 129823
On 6 Mrz., 00:41, sky46...@trline5.org wrote: > >> What did the chips & software cost at the time..? > >:) nothing / as not in shops... > >pretty much ALL electronic components sales at that time was black- > >market only. > >And almost all of them was stolen from the military fabs. > >There was very little in the official shops, the real component market > >was openly-hidden somewhere close by in big cities Moscow/St. > >Petersburg. In other places there was possible some "guy" coming each > >few weeks with "stuff" so you could "pre-order" things from him. Or > >you could go yourself to the cities where the fabs where and deal > >there yourself. Funny times. > >But when you ask the prices, actually I do recall the pricing, think > >not much > >different than now XC2064 around 15 USD I think. I recall it because > >in one design > >I used 13 GAL's what was not much more then price of cheapest Xilinx > >chip > >and the GAL's where around 1 USD > > I was mostly curious on the western market prices for the XC3030 + software. > Not the russian one, which for obvious reasons was not so straightforward as > the western one :) > Though the history of getting a XC3030 in the 1980s russia is interesting ;) XC2064,XC2018,XC3020 was "obtainable" XC3030 also, but I dont recall obtaining or using them http://www.flickr.com/photos/24388658@N02/2314268594/ here is an product based on XC3020, broadcast performance teletext inserter card, it was used in 80286 PC at Estonian TV station at some time, also in some cable network senders. re: XC3K, there was strong rumor that russians intended to clone some XC3K devices I think it was supposed to be done in the Kiev fab. I dont know how far it went but i think they never had any production. xilinx software and XACT dongle/schematics did arrive the UdSSR countries the same channel as the first XC2K/XC3K chips. XACT 3.2 on floppy disks. just out of curiosity i looked some more recent news about current products and developments: 5576HS1T clone of Altera EPF10K50, packaged in 256 flat military ceramic 5576HS2T functional clone of EPF8282, with runtime config CRC and RAD HARD improvments beside them, there are not much known about russian FPGA's, they mostly use BMK's base die with custom single layer metal process AnttiArticle: 129824
Dwayne Dilbeck wrote: > You should send the link to Xilinx. Sometimes companies will have a gallery > of devices that have used thier products. Having a device with an > interesting story like coming form the black market and used in developing > rusian spy technology, is just the thing marketing guys like to have to fill > time and showusefulness of the devices. Yes and no. If you make devices that still need export licenses, it may not be a good idea to have visible displays for the spooks, of how these did get (easily) into the 'wrong' hands :) -jg
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