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
My questin is: should I be able to write down some lines in abel, or can I use just the schematic and assign the pins somehow, like I was used to do with the pld tool under Orcad4? bye Strelnikov "Teo" <themarenas@comcast.net> ha scritto nel messaggio news:1122477005.077267.263940@z14g2000cwz.googlegroups.com... >I think it would be easiest to use Abel for a Gal device. You can find > examples undert c:/ispTools/examples/spld/gal > > Alternatively you could also just use a 32 m/c device like a 4032v and > do a schematic. Cost would likely be just a little more. > > Teo >Article: 87676
Duane Clark wrote:
> Tommy Thorn wrote:
>
>>
>> My sram memory interface works, but I've had to insert an idle cycle
>> to make the read data settle.
>>
>> Reading the spec for the IDT71V416S10 it claims both tAA and tRC to be
>> 10ns, with a tOH hold time of 4ns min hold time. I thus expected
>> something like this to work:
>>
>> always @(posedge clk100MHz) begin
>> sram_a <= <new addr>;
>> latched_data <= sram_d;
>> end
>>
>> where latched_data is from the previous address obviously. It worked
>> fine under simulation against the idt71v416s10.v model from IDT, but
>> on the board it wasn't reliable.
>>
>> I didn't supply any timing constraints for the FPGA pins connected to
>> the SRAM and I suspect that to be the problem, but I'm a bit unsure
>> what should I give as constaints. Suggestions?
>
>
> The problem is that you generate an address, it takes some finite time
> to actually get out to the pins, then more time to get to the SRAM, then
> the 10nS to get valid data, then more time to get back to the FPGA, and
> then a setup time to acquire latched_data. All of which adds up to more
> than the 10nS cycle time of your clock. But because the tAA is a worst
> case number, it looks like the actual times are adding up to very close
> to 10nS, and hence unreliable data.
Thanks, but I think you're missing my point. I want to use the SRAM in
a pipeline manner, capturing the data from the previous read in the same
cycle that I present new data. Assuming the delay of getting my address
to the SRAM is roughly equivalent to the delay getting the data back I
should only have to worry about the tOH (data hold time) of the SRAM
being large enough. At 4 ns I'm assuming it is.
And in fact, at 50MHz I can kind of do it. Here's a snippet of my state
machine:
S_READ: begin
if (data_latched != data_expected)
state <= S_FAILED;
else if (sram_a == N)
state <= S_SUCCEED;
else begin
sram_a <= addr;
data_latched <= sram_d;
data_expected <= lfsr[31:0];
addr <= addr + 18'd1;
lfsr <= lfsr_next;
state <= WITH_READ_WAIT ? S_READ_WAIT : S_READ;
end
end
The read cycle of 20ns should be *ample*, but for reasons I still don't
fully understand(*), the lower-order byte on the shared
Flash-Ethernet-SRAM bus on the Altera Nios Development Kit is slower
than the rest. Still the basic idea appears to be valid.
All that to say that I still don't understand how to use the timing
constraints for external pins. Does *anyone* use them? I haven't been
able to find any examples.
Thanks,
Tommy
(*): Only the lower order byte is shared with the flash ram with is a
clue, but the flash and ethernet is fully disabled. Sigh.
Article: 87677Hi Vladislav, with ISE7.1 SP3 I have seen the timing-driven p+p work on some designs. It even works on my own design, except when I use the option "register duplication" (-> results in that dreadful portability error). When I leave out all differential buffers in my design, it sudenly works. Unfortunately that's not really an option of course for my differential clock inputs :-( What I'm trying to say : apparently there's lots of bad combinations that can trigger the portability error. My suggestion : just try it for your design. If it doesn't => open a webcase or contact your FAE, the more noise we make, the sooner it will get fixed (I hope). best regards, BartArticle: 87678
Hi Vaughn, > The Quartus error message is correct. Yep. A remark saying something like "(1) Pin only supports single-ended I/O standards in F256 and T144 packages" would be helpful in rev 1.4. Updated my SR accordingly to clarify. Best regards, BenArticle: 87679
On 27 Jul 2005 16:45:51 -0700, ckpun1978@gmail.com wrote: > Is there a way to pass parameter to "do file" in the command line in >vsim? > Intuitively, it will be something like this > usr@host>vsim tb_dm -c -do mysim.do 1144 > (the 1144 is the parameter to be passed into mysim.do) > but it doesn't work... It doesn't work because Tcl treats "mysim.do" and "1144" as two completely separate arguments to the [vsim] command. So "mysim.do" is treated as the value of the "-do" option, and "1144" is an orphan. I can't remember the exact behaviour of the -do option, but you could make it work a slightly different way. The "-do" can be given either the name of a script, or a complete command. So this will be OK: vsim tb_dm -c -do "do mysim.do 1144" Note that the command goes in quotes. Tcl programmers might expect to use curly brackets instead, but if you're using Windows the OS command shell will smash it up into separate words. The double-quotes protect the Tcl command from processing by the shell. HTH -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 87680
Hey, I'm using a V4SX55-FF1148 ... an no, the errata doesn't mention anything about the configuration ... kind regards, Tim Verstraete Antti Lukats schreef: > "Tim Verstraete" <tim.verstraete@barco.com> schrieb im Newsbeitrag > news:AeQFe.155026$F25.8316022@phobos.telenet-ops.be... > > Hey all, > > > > I just made a V4 pcb and wanted to configure the FPGA through impact => > this > > works fine, so it says that the done pin goes high and everything is ok > but > > the code will not run because the GHIGH_B stays low ... but when i > configure > > the fpga through chipscope everything works, the GHIGH_B goes high and the > > vhdl is working ... how come??? > > > > i thought they both used the same process/dll/program to configure the > > fpga?? i think it has something to do with the properties of the impact > > program ... > > > > thanks in advance, > > > > kind regards, > > > > Tim Verstraete > > > > > > No. The configuration has been a problem at all times there is always some > combination of software and cables that work and some that do not. Some > times impact works and chipscope not. Sometimes chipscope does and impact > not. sometimes cable IV does not work and self made cable does. etc etc etc. > > A complete mess. > > for V4 check the early silicon errata about JTAG maybe it applies to your > chip, I think not but who knows. Hm what V4 are you using? I can add support > for it into our JTAG frequence meter application, it includes config support > for V4, then you could see if our software works better than impact. in the > current public online version I think only LX25 is supported but we could > easily add your FPGA device to the supported list just to see if it would > configure > > AnttiArticle: 87681
Hi Austin, Thanks for your help, Now it is clear that Xilinx devices do not tolerate dips. I would also have liked to understand why it is the case. Altera's devices have a similar level of complexity but I have not seen such constrains on their power-on specs. Cheers, Pablo "austin" <austin@xilinx.com> wrote in message news:1122489508.841246.175190@g14g2000cwa.googlegroups.com... > Pablo, > > Powering ON is a simple, yet tough thing to do well. > > We simulate ramps, and ramps with dips, and other things, and we test > with ramps, but we can't and don't simulate for every possible power > supply made. > > Thus, the typical power ON specification wants to see a "monotonic" > rise. > > In the strictest sense, this means that the slope is always the same > sign (never stops rising). > > Will it work if there is a plateau? Will it work with a slight dip? > > Generally, yes. But if you call, and say it does not work with your > ABC power supply, and that supply is not monotonic, we can say "sorry, > but we warned you that it doesn't work with every possible power supply > in the universe." > > If you use a power supply that does not comply (for example, all of our > listed power partners DO comply), then it is up to you to characterize > your board, and be sure it will work with all possible variations of > your powering solution. > > Austin > > Pablo Alvarez Sanchez wrote: >> Hi, >> >> If you read the specs of the XCFxxP PROMs, you find: >> >> http://www.xilinx.com/bvdocs/publications/ds123.pdf (page 22 of 42) >> >> "At power up, the device requires the VCCINT power supply >> >> to monotonically rise to the nominal operating voltage within >> >> the specified VCCINT rise time." >> >> >> >> Is monotonicity in VCCINT so important for the XCFxxP PROMs? Why? (I >> understand monotonicity= positive slope) , >> >> or the only important thing is that the oe/reset line is released once >> VCCINT is stable? >> >> Cheers >> >> >> >> Pablo Alvarez >Article: 87682
Hi, in Quartus there is an option "Remove Duplicate Registers / Remove Duplicate Logic". Is there something similar in Lattice ispLEVER 5.0 SP1 ? I want the fitter to keep duplicate registers but I do know where to make that setting. Thank you. Rgds Andr=E9Article: 87683
Hi everyone, in my design on a Spartan3 there are 9 GCLKs used, but there are only 8 available. Is the number of GCLKs related to the BUFG, or where can I change the design to use fewer of these global clocks. (I'm just using one single system clock at 100 MHz, but some BUFGs for DCMs, but not too much). Anyone can help? Thanks in advance, StefanArticle: 87684
idd, this patch has solved the virtex4 configuration problem ... i really don't know how i could overlook this AR? Thank you very much anyway ... kind regards, Tim VerstraeteArticle: 87685
Hi, Gated-clock conversion to clock-enable structures (most ASIC designs use this especially for low-power). FPGAs do not like gated clocks. Also, if you have used any standard IP blocks (e.g. Synopsys Designware), that may need to be converted. --NeerajArticle: 87686
Hello,
Philip Freidin wrote:
> Hi Alex,
>
> First let me thank you for what has to be a trully unique posting
> from a new participant to comp.arch.fpga .
Thanks. I've been around Usenet long enough to know what to do and,
more importantly, what not to do. The project is a learning experience
for me, I don't want anyone to give me the answer :-)
And thank you for your comments, they've helped me look in the
right directions. I'm a complete novice when it comes to FPGAs
and VHDL. So I've bought _The Student's Guide To VHDL_ by Peter J.
Anderson (ISBN 1558605207) based on various recommendations.
I've implemented a very simple siever limited to the IEEE 1164 INTEGER
type (signed 32-bit). Obviously this isn't much help for the final
version (64-bit numbers) but it's helping me understand the whole
thing.
The algorithm has changed slightly (and for the better). I have
eliminated the need for the decrement of r, and I'm now checking to
see if r is set to one of 9 values.
(I've been playing around with this today in a text editor. I
only have the Xilinx software at home on so please read through
any syntax errors :-)
(Also note that this is purely functional and unoptimised.)
function sieve_it
( p, c1, c2, c3, c4, c5, c6, c7, c8, c9 : in INTEGER )
return INTEGER is
variable n : INTEGER := 0;
variable r : INTEGER := 1;
begin
while n < 50000000 loop
r := r*2; -- double it (max p is 30 bits with signed integers)
-- with 64 bit unsigned integers then p can go up to
-- 2^63-1
n := n+1; -- increment n
if r >= p then
r := r-p;
-- r was 0 < r < p before being doubled.
-- after being doubled it must be 0 < r < 2p-2
-- so we will only ever need to subtract p once to bring it
-- back into the range 0 < r < p
-- since r is always +ve we never have to deal with negative
-- numbers. Should use unsigned integers but leave that until
-- later on.
end if;
-- r now holds 2^n mod p.
-- Check if r (2^n mod p) is equal to one of our target values
-- As far as concurrency is concerned, n must have been
-- incremented by this point. all other operations must be
-- performed sequentially.
if r=c1 or r=c2 or ... r=c9 then
-- got one, return n
return n;
end if;
end loop;
return 0;
end function sieve_it;
Up to 9 'check' values are provided, if not all values are needed then
a dummy value (either 0 or p) can be provided as r can never end up at
either of these values.
[MATHS BIT]
Computing test cases is easy. Consider k=19249 and p=100003. We are
looking to solve the discrete logarithm (= means equivalence):-
19249*2^n+1 = 0 (mod 100003)
=> 19249*2^n = -1 (mod 100003) : subtract 1 from each side
=> 2^n = -1 * 19249^-1 (mod 100003) : divide by 19249
(Don't worry how this bit works!)
19249^-1 = 3486 (mod 100003) : 3486*19249 = 1 (mod 100003)
=> 2^n = (100003-3486) (mod 100003)
=> 2^n = 96517 (mod 100003)
I can compute hundreds of thousands of these test cases per second on
a humble PC. This is not the tricky part.
There are 8 other candidate k values (aside from 19249), hence the
9 possible values to check for. Some checking (performed on a PC)
can eliminate certain k values (quadratic residues and Legendre
symbols) and so not all 9 c values may be needed.
[END OF MATHS BIT]
So we call sieve_it with p=100003 and c1=96517 (c2..c9 are all 0).
It should return n=9484 because 19249*2^9484+1 = 0 (mod 100003).
(Warning, this number has around 2900 digits so put your calculators
down.)
I don't care which value (c1 to c9) matched, in truth I don't really
care what the magic n value was. All I want to know is there was a
match for any n in the range 0..50M. Here's why...
The hits are so rare that just knowing that a certain p will provide
a result is all that is necessary.
Take the range of p from 882T (8.82*10^14) to 883T. I've sieved this
range with a software siever and so I know exactly how many factors
were found.
On average the prime density is about 1 in 33 in that range. So there
are roughly 1E12/33 = 3E10 primes between 882T and 883T. That's 3E10
individual calls to sieve_it() that need to be made. This is why I
want to fit as many sievers on the FPGA as possible, and make them
as fast as possible.
Out of those 3E10 primes, a mere 866 were factors of the numbers.
That's one hit for every ~ 35,000,000 calls to sieve_it.
So the plan is something like this:-
1. Implement and test sieve_it function.
I have a wrapper entity that sets up vars for the inputs,
calls sieve_it and then writes the result out to an input:-
entity proth_sieve is ( clk,reset : in STD_LOGIC;
nresult : out INTEGER )
end proth_sieve
...
proth_u_like : process is
begin
--assign values to tp,t1..t9
tp := 100003;
t1 := 96517;
result := sieve_it( tp,t1,t2,t3,t4,t5,t6,t7,t8,t9 );
nresult <= result after 100 ns;
wait on clk; -- sleep until restarted
end process proth_u_like;
I've also got another version of the siever that completes one
iteration of the loop per clock cycle. It writes out the current value
of r to an output port every loop and waits on the clk. That way I can
see what is going on with ModelSim.
2. Bolt on Serial port handler to allow communication between FPGA and
controlling PC. Don't know if Xilinx provides anything as part of
the Spartan-3 Starter Kit I purchased. There's always UART drivers
on www.opencores.org anyway.
PC --- Serial --- Simple_Controller --- Siever
The Simple_Controller is a just a pass through, it calls the
sieve_it() function directly and only when told to by the
PC via the Serial connection.
3. Have multiple sievers being handled by controller on the FPGA.
PC --- Serial --- Semi_Controller ---< Multiple Sievers
The Semi_Controller calls multiple siever functions, all
assignment handled by the PC via Serial.
4. Use the memory (1MB SRAM on Spartan-3 Dev Kit).
To upload work units (p,c1..c9) to memory
To download completed work units (p,result) from memory.
PC --- Serial --- Controller --- Memory
Sievers contact controller to request work unit from memory.
Sievers return results to controller which stores in memory.
Memory --- Controller --< Multiple Sievers
Sievers now controlled by the on board controller. If there
is work to do then controller assigns it itself.
The PC -> Controller interaction is only to upload/download
new/completed work units.
5. Optimise it, make it 64-bit, fit maximum number of sievers on
FPGA.
6. Drive other outputs on Spartan-3 Dev kit board?
8 LEDs - Controller status, Serial activity (upload/download)
4-digit 7-segment display - # of work units processed per second?
VGA output - crude graphical siever status, i.e.
5 scan lines per siever, LHS of screen is n=0, RHS is n=50M
line scaled appropriately.
This last stage would be pure overkill and I'd be happy to ignore
them if they are to the detriment of the overall sieving performance
of the FPGA (i.e. they take up space that could house another siever)
but it would be nice to see the blinkenlights on the board put to
some use.
Ta,
-Alex
Article: 87687Randy Yates wrote: > > It's a fact. > I doubt it! Our marketplaces (or those of the companies we work for) are quite different... Ciao, Peter K.Article: 87688
Stefan, You cannot have 9 GCLKs, as S3 has only 8, yet there are only 8 BUFGs. You may have a limitation of interconnect between DCMs and respective BUFGs. Can you explain a bit more? Vladislav "Stefan" <holzi_stefan@hotmail.com> wrote in message news:dca9si$hdu$1@wsc10.lrz-muenchen.de... > Hi everyone, > > in my design on a Spartan3 there are 9 GCLKs used, but there are only 8 > available. Is the number of GCLKs related to the BUFG, or where can I > change > the design to use fewer of these global clocks. (I'm just using one single > system clock at 100 MHz, but some BUFGs for DCMs, but not too much). > Anyone can help? > > Thanks in advance, > > Stefan > >Article: 87689
Bart, I am so sorry I forgot to add that I am using 7.1 SP3 and I am able to make timing driven PiP working by turning off "reg. dupl." :) I was just wondering if there is a progress with it, as I have to pipeline parts of the design to meet timing. I have opened a case and i was told that this is a known issue, so if i do not send my NGC/EDF, in 2 business days case closed --> completely understandable. Speaking about the noise... This is a noise! Thanks!!! Vladislav "zeeman_be" <zeemanbe@gmail.com> wrote in message news:1122534054.444433.89750@o13g2000cwo.googlegroups.com... > Hi Vladislav, > > with ISE7.1 SP3 I have seen the timing-driven p+p work on some designs. > It even works on my own design, except when I use the option "register > duplication" (-> results in that dreadful portability error). When I > leave out all differential buffers in my design, it sudenly works. > Unfortunately that's not really an option of course for my differential > clock inputs :-( > > What I'm trying to say : apparently there's lots of bad combinations > that can trigger the portability error. My suggestion : just try it for > your design. If it doesn't => open a webcase or contact your FAE, the > more noise we make, the sooner it will get fixed (I hope). > > best regards, > Bart >Article: 87690
Hi,
I am using Xilinx ISE 7.1.02i and Synplify 8.0; recently updated to
Synplify 8.1.
Synthesizing the VERILOG code
`timescale 1ns / 1ps
module adder4_simple(
input wire CLK,
input wire [7:0] IN_1,
input wire [7:0] IN_2,
input wire [7:0] IN_3,
input wire [7:0] IN_4,
output reg [9:0] OUT
);
always @(posedge CLK) begin
OUT <= IN_1 + IN_2 + IN_3 + IN_4;
end
endmodule
using Synplify 8.0 and then looking at the synthesis report, I get an
estimated frequency of 198.4 MHz - see the following synthesis report
section:
[code:1:ba43749246]
Performance Summary
*******************
Worst slack in design: 994.960
Requested Estimated Requested
Estimated Clock Clock
Starting Clock Frequency Frequency Period
Period Slack Type Group
----------------------------------------------------------------------------------------------------------------------------
function_simple|CLK 1.0 MHz 198.4 MHz 1000.000
5.040 994.960 inferred Inferred_clkgroup_0
============================================================================================================================
[/code:1:ba43749246]
After I updated to Synplify 8.1, the report does not give this
information anymore:
[code:1:ba43749246]
Performance Summary
*******************
Worst slack in design: NA
[/code:1:ba43749246]
Is there anyone else who has encountered this problem, and is there a
way to get estimated frequency information using Synplify 8.1?
Thanks for any answers,
Hagen
Article: 87691Hi Let me continue this discussion. In case, we have additional input ports (signals), for example, "reset" or some "enable" ports, it seems that "ILA" and "Analyzer" are not enough for the on-chip verfication. It seems that we need "VIO" core as a input signal generation. Is it correct? Can we verify the logic with only "ILA" and "Analyzer" in this case ? Thankyou again, RegardsArticle: 87692
Marc, It turns out that if you are going only to the DFS, and you do not move the frequency very fast, you can sweep from min to max input (output) frequency before losing lock. The DLL is fussier, as it chooses to arrange its six delay lines based on what options, range, and where it locks. So in the DLL, if you start sweeping the frequency, you may get an overflow or underflow on one of the delay lines, and lose lock. We typically spec +/- 100 ppm, because just about any trashy crystal can do that. In reality, +/- .01 is probably safe. AustinArticle: 87693
Tommy Thorn wrote: > Duane Clark wrote: >> Tommy Thorn wrote: >> >>> My sram memory interface works, but I've had to insert an idle cycle >>> to make the read data settle. >>> >>> Reading the spec for the IDT71V416S10 it claims both tAA and tRC to be >>> 10ns, with a tOH hold time of 4ns min hold time. I thus expected >>> something like this to work: >>> >>> always @(posedge clk100MHz) begin >>> sram_a <= <new addr>; >>> latched_data <= sram_d; >>> end >>> >>> where latched_data is from the previous address obviously. It worked >>> fine under simulation against the idt71v416s10.v model from IDT, but >>> on the board it wasn't reliable. >>> >>> I didn't supply any timing constraints for the FPGA pins connected to >>> the SRAM and I suspect that to be the problem, but I'm a bit unsure >>> what should I give as constaints. Suggestions? >> >> The problem is that you generate an address, it takes some finite time >> to actually get out to the pins, then more time to get to the SRAM, then >> the 10nS to get valid data, then more time to get back to the FPGA, and >> then a setup time to acquire latched_data. All of which adds up to more >> than the 10nS cycle time of your clock. But because the tAA is a worst >> case number, it looks like the actual times are adding up to very close >> to 10nS, and hence unreliable data. > > Thanks, but I think you're missing my point. Hmmm... reading what you have below, I don't think so... > I want to use the SRAM in > a pipeline manner, capturing the data from the previous read in the same > cycle that I present new data. Assuming the delay of getting my address > to the SRAM is roughly equivalent to the delay getting the data back I > should only have to worry about the tOH (data hold time) of the SRAM > being large enough. I think you have a fundamental misunderstanding there. The two delays mentioned add up, and along with the input setup time, need to be less than the clock cycle time. For the 100MHz clock previously mentioned, they do not. Also these delays create an artificial hold time that makes the tOH of the memory chip completely irrelevant. You seem to have switched boards on me, and I don't have Altera specs handy. But on the previous board mentioned with a Virtex2P chip, the registered inputs do not even have a hold time requirement, only the setup time. > ... > The read cycle of 20ns should be *ample*, but for reasons I still don't > fully understand(*), the lower-order byte on the shared > Flash-Ethernet-SRAM bus on the Altera Nios Development Kit is slower > than the rest. Still the basic idea appears to be valid. Yes, 20nS should be enough if the only thing there is the SRAM, and assuming the Altera timing is similar to the Xilinx timing. But you need to check several thing. First, when you say the flash and ethernet are fully disabled, do you mean they are never enabled? Have you verified that is really the case? Have you verified that all signals to and from the SRAM are registered within the IOBs of the FPGA? Including the data output enable signals? I assume Altera has something similar to FPGA editor to make sure this is really the case. > > All that to say that I still don't understand how to use the timing > constraints for external pins. Does *anyone* use them? I haven't been > able to find any examples. Assuming that ALL inputs and outputs, including output enables, are registered, then timing constraints on external pins are completely irrelevant, and will have absolutely no effect. The timing is fixed, and can be obtained from the FPGA data sheet. In general, you should be registering all these signals within the IOBs. You should need a very good reason not to.Article: 87694
Does XST 7.1 support TCL scripting? I don't see any mention of it in the XST User Manual and I find the command line mode to be very awkward performing synthesis using the GUI or command line without a script. I'm new to XST, and I'm looking for ways to organize my synthesis process. By default the tool dumps all of synthesis files all over the place, ugh. I was hoping I could have some control over all this, which I could do it. If anyone has any recommendations to using XST in command line I'm all ears. Much appreciated, BrandonArticle: 87695
"Antti Lukats" <antti@openchip.org> wrote in message news:dc87bd$knm$03$1@news.t-online.com... > > they are NOT, available are only IEEE1532 files for XCFxxS not for XCFxxP !! OK, I see now what you mean. I assumed there was only one BSDL standard. Can you please explain what this IEEE1532 is all about compared to "regular" bsd files? Thanks, /MikhailArticle: 87696
I'm working with avnet v2p dev board trying to communicate with the device via the pci bus right now i want to see if any of the signals i'm sending over the bus is recieved by the device. This means using chipscope.. i think. I can add a chipscope core to the design and synthesize and generate a bit file, then configure the v2p I monitor the signal TRGT_IRQ to see if the device is seeing it when i write it to the pci BUS. I use an internal DCM to generate a 50 mhz internal clock now when i try to use chipscope to connect and monitor the board the program sits and waits with no response from the jtag chain. (however i can fire up impact and configure various devices via the jtag chain, so i know the jtag cable is functioning) is there some board setting that needs to be changed? do i need to assigned specific I/O pins to the top level design for the jtag chain to work? thanks for your help. -- Geoffrey Wall Masters Student in Electrical/Computer Engineering Florida State University, FAMU/FSU College of Engineering wallge@eng.fsu.edu Cell Phone: 850.339.4157 ECE Machine Intelligence Lab http://www.eng.fsu.edu/mil MIL Office Phone: 850.410.6145 Center for Applied Vision and Imaging Science http://cavis.fsu.edu/ CAVIS Office Phone: 850.645.2257Article: 87697
"MM" <mbmsv@yahoo.com> schrieb im Newsbeitrag news:3kspnkFvdd0qU1@individual.net... > "Antti Lukats" <antti@openchip.org> wrote in message > news:dc87bd$knm$03$1@news.t-online.com... > > > > they are NOT, available are only IEEE1532 files for XCFxxS not for XCFxxP > !! > > OK, I see now what you mean. I assumed there was only one BSDL standard. Can > you please explain what this IEEE1532 is all about compared to "regular" bsd > files? > > > Thanks, > /Mikhail > there is one VERY BIG difference. the IEEE1532 BSDL contains ALL the programming algorithm information needed to program the device using IEEE1532 compatible Software. A plain BSDL file does not contain this information. So if a company, (Xilinx as example) does not publish some programming algorithm, but DOES publish the IEEE1532 compliant BSDL files for the device in question then you can either extract the programming algorithm from IEEE1532 BSDL file or use IEEE1532 software to programm the device in question. So that makes the difference very important. Xilinx promised the XCFxxP IEEE1532 BSDL files to be made available in 2006, but to all my best knowledge the current (non-ES! ) XCFxxP silicon has features that makes the XCFxxP not programmable in true plain IEEE1532 software, so Xilinx would not be able to deliver the XCFxxP IEEE1532 BSDL files in 2006 unless they fix the silicon or the IEEE1532 standard. And even if they fix the silicon by 2006, it still would not help me to program the XCF08P today. Our client is waiting for solution. And will defenetly not wait til 2006!!! I am still waiting for the WebCases solutions, but so far nothing helpful. I was promises of some sort of reply by monday. Lets see. AnttiArticle: 87698
Hi, I will repost the message I recovered posted in 1998 and modify it a little. I've got a fairly old Lattice GAL programer Called "Logic Lab", it was made by Programable Logic Tech. I have a few problems with it It seems to be very fussy about the exact type of Lattice 16V8 and 20V10 GALs it accepts, rejecting most varients with an "incorrect device" message. I suspect this is because the software (ll.exe) is too old to know what these varients are. I have also the second version ll2.exe but when I start it up on a 486DX it is always returning the message "programmer is not responding". On a windows based system it won't even start up " the program is trying to communicate with com1 ..." I've had a look for info on Programable Logic Tech on the internet but they seem to have disappeared, certainly the Lattice web sight doesn't list them as programmer suppliers anymore, they are listed in the old Lattice data books. I think it's a bit of shame to throw the programmer away. I need it ! Has anyone advice / experience with it ? A GAL type A,B works pretty well with ll.exe but I doubt if it is even possible to obtain these pretty old devices. Many thanks, Eng. Geert DBArticle: 87699
austin wrote: > Marc, > > It turns out that if you are going only to the DFS, and you do not move > the frequency very fast, you can sweep from min to max input (output) > frequency before losing lock. > > The DLL is fussier, as it chooses to arrange its six delay lines based > on what options, range, and where it locks. So in the DLL, if you > start sweeping the frequency, you may get an overflow or underflow on > one of the delay lines, and lose lock. > > We typically spec +/- 100 ppm, because just about any trashy crystal > can do that. In reality, +/- .01 is probably safe. Austin, Suppose the clock starts as 'any trashy crystal', but is then fed via another Xilinx DLL - is there a chain-limit of jitter degradation, in such a system ? This will become a more common scenario... -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