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
Hi, The following Xilinx Xcell article describes how you can use the JTAG port of a Xilinx FPGA as a general comms channel to a design. One of the uses we have for it is to replace the RS232 as the serial comms channel to designs. http://www.xilinx.com/publications/xcellonline/xcell_53/xc_jtag53.htm The example GNAT design can be downloaded for free from here. http://www.s3group.com/system_ic/gnat/ It includes the GNAT design and also supplies some sample TCL illustrating how you can pass data into and out of the FPGA. Derek nchandra@gmail.com wrote: > Hello, > > Is it possible to use a JTAG cable connection to transfer data into and > out of an FPGA during regular operations? The situation is like this: > we have a Xilinx Spartan 3 board that we are programming with a > digilent parallel cable. This works fine. We would also like to > transfer data into and out of the FPGA, for which we are currently > using serial communications (RS232), but the data rate is now becoming > a bottleneck. > > The JTAG cable, connected through the parallel port, should be capable > of doing much higher speeds than RS232. It is, however, connected to > the JTAG pins of the FPGA. Can this somehow be used to transfer data in > and out without redesigning the board in any way? Is there any software > that could be a starting point for this? > > Thanks, > > Nitin Chandrachoodan >Article: 91851
ashwin wrote: > Hello Everyone again, >[snip] > Probably the data is getting transferred on to the PC, but not able to > capture it since, i am not pinging it. So how do we see what data is > coming out from the PHY. > > Please advice ? With a fast digital oscilloscope ? Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 91852
PiyushG schrieb: > Hi all > I have problem in designing a circuit which is recursive > > Suppose i am designing a schematic of BRLSHIFTER and suppose i want > assign all outputs to inputs then what changes should I made in ".vhf" > file? > > Thanking you > Hi Piyush, first of all...why do you want to manipulate your *.vhf file? if you are designing a schematic, you can use your schematic editor, which creates a *.sch file. The *.vhf file is generated from the schematic file, and might be overwritten by the IDE. Now, if you already have designed your barrelshiftersave it, go back to the ide and generate a symbol out of the schematic (Look under design entry tools). Open a new schematic and place the barrel schifter symbol there. Well, now you are free to connect the outputs to the inputs with a bus or wires, if it makes any sense. Maybe you should think about a multiplexer, to feed in your initial data and then switch to the feedback, and a register would be nice to prevent a combinatorial loop, if your barrel shifter doesn't already have it. At last please tell me what you mean by "recursive"? Recursion is not equal to feeding data back into a function (block), which can be seen as looping. In software it only works, because you have lots of RAM and your function can allocate new workspaces (for variables etc.) until the problem deepth is reached and the results can be accumulated somehow on the way back to the first calling function, or...until your ram limit is reached. (Without thinking about the stack) This is a virtual behavior. Workspaces are created as needed. How should that happen in hardware? Function blocks do not virtually pop out of nowhere. It is surely possible to create a hardware that behaves to a certain limit like a recursive algorithm, but then, only a very limited number of algorithms need real recursion. In software mostly everything can be expressed different, though not even as elegant. have a nice synthesis EilertArticle: 91853
Or with a not so fast oscilloscope if you force 10Mb/s from the PC end link.
Aurash
Rene Tschaggelar wrote:
> ashwin wrote:
>
>> Hello Everyone again,
>> [snip]
>> Probably the data is getting transferred on to the PC, but not able to
>> capture it since, i am not pinging it. So how do we see what data is
>> coming out from the PHY.
>> Please advice ?
>
>
> With a fast digital oscilloscope ?
>
> Rene
--
__
/ /\/\ Aurelian Lazarut
\ \ / System Verification Engineer
/ / \ Xilinx Ireland
\_\/\/
phone: 353 01 4032639
fax: 353 01 4640324
Article: 91854
Hi,
I have followed the design in systemC, but I have some troubles when
instantiating multiples components. In bankreg.h I have the
instantiation of several registers.
The problem is that after execution, I have the following errors for
each register:
Warning: (W505) object already exists: bankreg.memory.port_0. Latter
declaration will be ignored In file: sc_object.cpp:164
Warning: (W505) object already exists: bankreg.memory.port_1. Latter
declaration will be ignored In file: sc_object.cpp:164
Warning: (W505) object already exists: bankreg.memory.port_2. Latter
declaration will be ignored In file: sc_object.cpp:164
Warning: (W505) object already exists: bankreg.memory.port_3. Latter
declaration will be ignored In file: sc_object.cpp:164
Warning: (W505) object already exists: bankreg.memory.port_4. Latter
declaration will be ignored In file: sc_object.cpp:164
Warning: (W505) object already exists: bankreg.memory.behaviour. Latter
declaration will be ignored In file: sc_object.cpp:164
Error: (E112) get interface failed: port is not bound: port
'bankreg.port_4' (sc_out)
Error: (E112) get interface failed: port is not bound: port
'bankreg.port_7' (sc_out)
Find attached both .h files:
//bankreg.h
#include "librairie.h"
#include "reg.h"
#ifndef __bankreg_h__
#define __bankreg_h__
SC_MODULE(bankreg) {
//sc_in<bool> clearn;
sc_in<sc_uint<MAX_BIT> > new_data[MAT_WIDTH];
sc_in<bool> enable_data;
sc_in<bool> clk;
sc_in<bool> reset_intern;
sc_out<sc_uint<MAX_BIT> > output[MAT_LENGTH][MAT_WIDTH];
sc_signal<sc_uint<MAX_BIT> > out_reg[MAT_LENGTH][MAT_WIDTH];
SC_CTOR(bankreg) {
reg<MAX_BIT> *memory[MAT_LENGTH][MAT_WIDTH];
for (int i=0; i < MAT_LENGTH; i++) {
for (int j=0; j < MAT_WIDTH; j++) {
memory[i][j] = new reg<MAX_BIT>("memory");
if (i==0) {
memory[i][j]->input(new_data[j]);
memory[i][j]->enable(enable_data);
memory[i][j]->clearn(reset_intern);
memory[i][j]->clk(clk);
memory[i][j]->output(out_reg[i][j]);
} else {
memory[i][j]->input(out_reg[i-1][j]);
memory[i][j]->enable(enable_data);
memory[i][j]->clearn(reset_intern);
memory[i][j]->clk(clk);
memory[i][j]->output(out_reg[i][j]);
}
}
}
for (int i=0; i < MAT_LENGTH; i++) {
for (int j=0; j < MAT_WIDTH; j++) {
output[i][j] = (out_reg[i][j]).read();
}
}
}
};
#endif
//reg.h
#include "librairie.h"
#ifndef __reg_h__
#define __reg_h__
template <int size> SC_MODULE(reg) {
const static int MAX = size;
sc_in<sc_uint<MAX> > input;
sc_in<bool> enable;
sc_in<bool> clearn;
sc_in<bool> clk;
sc_out<sc_uint<MAX> > output;
unsigned int value;
void behaviour() {
if (clearn == false){
value = 0;
} else if (enable) {
value = input.read();
} else { value = value;
} output = value; }
SC_CTOR(reg) {
SC_METHOD(behaviour);
sensitive_pos << clk;
} };
#endif
Many thanks for your help. Moreover, does anybody know any site to
visit in order to get SystemC examples?
Moises
Article: 91855Hi Folks, I just wanted to make you aware of an open research position we have at WSI/GRIS, Tuebingen University, Germany, in the area of FPGA design, physical simulations, and computer graphics. If you're interested, have a look at our web site at http://www.gris.uni-tuebingen.de/ The project title is: "Hardware-Accelerated Simulations of Textiles and Tissue". Regards, G. KnittelArticle: 91856
To expand on Rene's comment, there's no way around RoHS compliance **anywhere**. Molex, for instance, has obsoleted all it's high density parts (to my knowledge) in favour of new RoHS compliant parts. They are probably doing this across the board, as they don't want to keep different stocks on hand with the logistics nightmare involved. As to high speed problems: Different materials will undoubtedly cause impedance vectors to change. In addition, the loss tangents across materials (very important in extremely high frequency designs) will vary. Whether they will be better or worse is unknown, but after all the research into existing materials, my take is they will be worse. IC packaging will have to change. Most existing plastic packages have absolute maximum temperature ratings of about 220C, but the RoHS reflow profile is well above this (about 260C). See this Xilinx app note: http://direct.xilinx.com/bvdocs/appnotes/xapp427.pdf Changing the materials to make a device compatible with those reflow characteristics is bound to have an effect somewhere, although I don't know the specifics for Xilinx. In addition to that, the solder joint of a tiny part (such as a coupling cap) has parasitics that are (somewhat) material dependent. Change the materials, change the parasitics. This too is an issue for high speed designs. Note - when I mention extremely high frequencies, I am referring to bit times (on the wire pair) of 1nSec or less (PCI express, InfiniBand and Fibre channel come to mind). So will it affect us in high speed designs? Undoubtedly. The issue is we probably won't know the effects until there are large numbers of boards already made. Cheers PeteSArticle: 91857
PeteS wrote: [snippage] > In addition to that, the solder joint of a tiny part (such as a > coupling cap) has parasitics that are (somewhat) material dependent. > Change the materials, change the parasitics. This too is an issue for > high speed designs. The thermal resistance will also be different. (I don't know whether it will be better or worse, but Murphy says it will be worse.) A significant amount of heat leaves the package through the balls, and this may matter for high speed designs. Regards, AllanArticle: 91858
john wrote:
>
> with my version of ISE, I can not put the IOB attribute on a signal
>
I rebuilt that example 6.3 project I'd posted a link to, using 7.1SP4
The IOB attribute worked just fine (note 1); the tristate controls are
properly replicated and all registers show up in the IOBs.
>
> I get the error
> ERROR:HDLParsers:1202 - "/home/XXX/XXX/XXX.vhd" Line 210. Redeclaration of symbol tristate_enable_reg. -->
>
That message sounds like the synthesizer is choking on a coding
problem. Do you have duplicate (identical) names for both a process
and a signal, or something similar ?
Brian
Note 1:
There is a 7.1iSP4 bug with assigning IOSTANDARDs and LOCS
using HDL attributes. Unused LOC'd inputs drop their IOSTANDARD
definitions and default back to LVCMOS25, causing banking errors.
To make that example project compile, make the following change to
<ram_test.vhd> to avoid any unused inputs:
-- seg_dp <= '1';
seg_dp <= sw(5) OR sw(4) OR sw(3) OR sw(2) OR sw(1) OR sw(0)
OR pb(1) OR pb(0);
Article: 91859Hi there, I am encountering a strange problem in a state machine using a 33M3333 clock in a Spartan3 FPGA. >From time to time, the state machine misbehaves. The problem has at first been attributed to a relatively poor waveshape of the clock line. A load of 100ohms/10pF in series to ground has been put at the end of the line, improving a bit the problem. However, the problem is still there. I am now suspecting a too slow rise time or fall time of the clock input to the FPGA, that could let a noise go through around the threshold point. This idea is backed up by the fact that extra edges seem to be added. By the way, I am unable to find in the Xilinx data sheet any value for the RT and FT of the clocks. I would have liked to be able to force input hysteresis on the clock signals, but I think it is not possible nor maybe desirable. Any idea ?Article: 91860
..A significant amount of heat leaves the package through the balls, and this may matter for high speed designs. ... Very true (not so much if it's a flipchip ;) It will most definitely change the thermal characteristics. That being the case, we'll either get poorer guaranteed performance, or poorer temperature ranges. I'd take the termperature range and cool it (of course, that adds a whole new dimension). Cheers PeteSArticle: 91861
abeaujean@gillam-fei.be wrote: > Hi there, > > I am encountering a strange problem in a state machine using a 33M3333 > clock in a Spartan3 FPGA. > > >From time to time, the state machine misbehaves. The problem has at > first been attributed to a relatively poor waveshape of the clock line. > A load of 100ohms/10pF in series to ground has been put at the end of > the line, improving a bit the problem. > > However, the problem is still there. I am now suspecting a too slow > rise time or fall time of the clock input to the FPGA, that could let a > noise go through around the threshold point. This idea is backed up by > the fact that extra edges seem to be added. By the way, I am unable to > find in the Xilinx data sheet any value for the RT and FT of the > clocks. > > I would have liked to be able to force input hysteresis on the clock > signals, but I think it is not possible nor maybe desirable. > > > Any idea ? When you say you put a load at the end of the line, are you saying the end of the line is not at the Spartan? Were you able to put a scope at the pin of the FPGA? If the clock driver doesn't have a low enough output impedance and the Spartan is not at the end of the line, you could be seeing a stepped transition where the clock actually sits in the threshold region for a while until the reflected wave brings the voltage up. Since your clock seems to be slow, I don't see why hysteresis would be a bad idea, unless the data you capture externally has a small setup/hold window. In the case of the stepped transition, hysteresis would delay the clock edges until the signal reflection. The extra delay from this depends on the length of trace between the Spartan and the end of the line. The best fix of course would be to route the clock only point to point, using zero delay buffers if necessary to fan out. Then a proper clock signal would be achievable using only series termination at the source (or buffer).Article: 91862
"fad" <fahad.arif@gmail.com> writes: > I dont think you require anything else. For in circuit debugging.. all > you need is.. > 1) JTAG cable 2)ChipScope Pro 3)Impact for programming (which comes > with ISE only) Chipscope will program as well, no need for Impact. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.trw.com/conektArticle: 91863
Thanks for the prompt answer. The input pin of the FPGA is actually very near to the end of the line, where the R/C load sits. No, I have not been able yet to look at the waveform "near to the pin" (the configuration is not easily accessible). OUPS. Glad you talk about the "driver" chip anyway. Reviewing my parts list (and not only the schematics that do not clearly show that) makes me realize that it is a 74LVC2244 (with 30 ohms series termination in it). That should not look too good with the RC termination. SO. I shall first try a 74LVC244A instead and see what happens. By the way, I see no way to force an input hysteresis in a Spartan3 FPGA.Article: 91864
Key to a clean clock either (1) Using termination either series at source, or parallel at endpoint (2) Limiting clock edge rate to reduce reflections. To think sideways you problem sounds very like the classic asyncronous input, or not meeting setup/hold, problem. Are any of you inputs to your state machine asynchronous(or different clock) to the clock used for the state machine? John Adair Enterpoint Ltd. - Home of Raggedstone. The Cheap Spartan3 Development Board. http://www.enterpoint.co.uk <abeaujean@gillam-fei.be> wrote in message news:1132060488.081334.147800@f14g2000cwb.googlegroups.com... > Hi there, > > I am encountering a strange problem in a state machine using a 33M3333 > clock in a Spartan3 FPGA. > >>From time to time, the state machine misbehaves. The problem has at > first been attributed to a relatively poor waveshape of the clock line. > A load of 100ohms/10pF in series to ground has been put at the end of > the line, improving a bit the problem. > > However, the problem is still there. I am now suspecting a too slow > rise time or fall time of the clock input to the FPGA, that could let a > noise go through around the threshold point. This idea is backed up by > the fact that extra edges seem to be added. By the way, I am unable to > find in the Xilinx data sheet any value for the RT and FT of the > clocks. > > I would have liked to be able to force input hysteresis on the clock > signals, but I think it is not possible nor maybe desirable. > > > Any idea ? >Article: 91865
Is the ability to speak German a requirement, or is there an english version of this website available? StephenArticle: 91866
Downloading and installing SP4 from the Xilinx site eventually solved my problems... johannesArticle: 91867
100 Ohm + 10 pF in series is not a meaningful termination. R should = the char. impedance, probably 50 Ohm. C should give it a time constant that is longer than a transition time, but shorter than a clock half-period. Make that 10 ns in your case. That means 50 Ohm + 200 pF. But this assumes that you want to do a parallel termination at the far end. If your driver has a series termination, then you want to keep the far end unterminated, but you then also accept a step function everywhere along the line, except at the far end. If you suspect double-triggering, then just implement a free-running 2-bit counter in the FPGA and look at its outputs. That will indicate double-triggering very clearly. Peter Alfke, Xilinx Applications.Article: 91868
Hi Arlet The format i used for the ethernet frame is this: WIth the least significand bit transferred first. I have a 4 bit interface from fpga to PHY so i will transfer least significand nibble of each byte every clock cycle. 7 bytes of x"55"; 1 byte of x"d5"; 6 bytes of dest MAC address 6 bytes of source MAC address DATA -- 40 bytes 4 bytes of FCS What do you mean by static IP packet. Does it include preamble and CRC too? The PHY converts the data into MLT-3 signal which is like a sinusoid. Its hard to decode manually what data is being sent out. Ashwin Arlet wrote: > Ethereal has no problems showing non-IP packets when it catches them. > > Are you sending the correct preamble and SFD ? Do you see the link > blink on the PC whenever you send something ? Manually copy a static IP > packet bit by bit in your VHDL code, and send that as a test packet. > Compare your version with the sample bit file by looking at PHY signals > with a scope.Article: 91869
Sorry for not mentioning this. On the far right on our web page, you find three little flags, one of them is for English. Speaking German is not a requirement as long as we can communicate sufficiently well in English. Cheers Guenter "Stephen Craven" <scraven@vt.edu> wrote in message news:1132065691.562056.193150@z14g2000cwz.googlegroups.com... > Is the ability to speak German a requirement, or is there an english > version of this website available? > > Stephen >Article: 91870
The 4:1 rule is a very good starting point since it covers the range of variability in the most important delay mechanisms within a CMOS process. However, it is important to remember that it is just that, a scaling of the delays related to channel conductance, capacitances, and internal wire propagation. When the delays you are considering consist of these factors, then the 4:1 rule is good. However, to be REALLY REALLY picky, there are some cases where you have to be careful with the 4:1 rule for I/O timing. Specifically, it is questionable to apply this rule to one of the main delay parameters in the the FPGA datasheet, Tickofdcm. Tickofdcm (or Tickofdll) is a composite parameter that relates the timing of an output to the arrival of the clock at the FPGA clock input. This path goes through a lot of things (the IBUFG, a DCM/DLL with internal feedback, the GCLK buffer and global clock net, the output flip-flop in the IOB and then the final output driver in the IOB). Many of these are appropriately scaled using the 4:1 rule, but the some aspects of the clock and DLL are not... The DLL/DCM with internal feedback is, in fact, designed specifically NOT to scale with the 4:1 rule; that is the whole reason that we use one; to cancel out the delay of the clock distribution net (and associated other circuitry), even though that circuitry does scale with process temperature and voltage. If the cancellation of the clock net by the DLL were perfect, then this portion of the path would contribute no delay to Tickofdcm, and hence the 4:1 rule would apply to the whole path. However, this is not the case. The DCM is not perfect, and, in some systems, is intentionally designed to result in a slightly negative total delay. By doing this, Xilinx reduces the required hold time at input FF's in the IOBs, resulting in a negative (or at least very small) required hold time (Tphdcm). However, applying the 4:1 scaling factor to this portion of the delay results in a slightly OPTIMISTIC value. To be quite paranoid (and I admit, that for most designs this is excessive, since the 4:1 rule is pretty generous, and will cover a little "slop" in the path), you should scale Tickofdcm differently. For the min of this parameter, I would use Tickofdcm(min) = Tickofdcm(max) - 3/4Tiockp(max) as a starting point. The values for both of these parameters should already be derated for the appropriate I/O standard being used. Note: this can acutally result in a negative number for certain I/O standards, and is technically correct, due to the negative delay of the DLL/clock tree combination. Also, Tickofdcm contains some allowance for the phase error and jitter of the DCM. For Tickofdcm(max), these are assumed to be their worst case in the positive direction, for Tickofdcm(min), they need to be accounted for in the negative direction, so for a TOTALLY paranoid application Tickofdcm(min) = Tickofdcm(max) - 3/4Tiockp(max) - 2xCLKOUT_PER_JITT0 - 2xCLKIN_CLKFB_PHASE And finally, the system designer must not forget to factor in the clock jitter on the input clock, which adds to Tickofdcm(max), and subtracts from Tickofdcm(min). This can get somewhat tricky, since it is a bit pessimistic to add the external clock jitter directly to the jitter added by the DLL/DCM; these jitters are probabilistic, and hence add probabilistically; truly random jitters add using a root-sum-of-squares calculation. Avrum "Ajay" <ajay@cg-coreel.com> wrote in message news:1131886868.567328.63420@g44g2000cwa.googlegroups.com... > Thank you so much Peter. We are using the 4:1 rule. > > Regards, > Ajay > > Peter Alfke wrote: > > Yes, I agree. > > Inside the chip, we make sure that the delay tolerances on a global > > clock are less than the min delay clock-to-Q, and we can guarantee > > that, since delays track inside the chip. > > Between chips, the min delay is important since the clock delay > > differences are determined by the pc-board, and the transmitting device > > may also have nothing in common with the receiving device (neither > > temperature nor processing, although probably voltage). > > > > That's why source-synchronous design is now popular (sending the clock > > together with the data) and IDELAY in Virtex-4 gives you the ability to > > delay clock or data by a precise amount, so that you can achieve > > near-optimal relative timing. > > Peter Alfke >Article: 91871
Hi Ashwin, What about the 8b/10b encoding, are you encapsulating your ethernet packets with the SOP, EOP and Carrier Extend as specified in the ieee 802.3 spec... It's been a while but I seem to remember that in my case (my own tri-rate mac+2vp rocketIO+external sgmii SFP) I had to encapsulate the data you decribed as: SOP >>7 bytes of x"55"; >>1 byte of x"d5"; >>6 bytes of dest MAC address >>6 bytes of source MAC address >>DATA -- 40 bytes >>4 bytes of FCS EOP + CS Also make sure you send IDLEs when you don't transmit your packet... Regards, -- Ignacio U. Hernandez " I'm not normally a praying man, but if you're up there, please save me, Superman!" - Homer Simpson ;O) "ashwin" <achiluka@gmail.com> wrote in message news:1132010843.945625.155910@o13g2000cwo.googlegroups.com... > Hello Everyone again, > > This topic is troubling me for couple of weeks now. I want to > get over this as quickly as possible. I am trying to transmit data from > the virtex 4 LX fpga board to the PC using ethernet PHY and i am > unable to detect any data on the PC. > I have written a small state machine using vhdl which actually > transmits the ethernet packet( dest MAC, Source MAC, length/type, data, > fcs(Crc)] . I am sure that FCS is correct as i tested my code for > sample ethernet packets and i got it right. > > There is a sample bit file given with the evaluation board to me > for testing the ethernet PHY.So when i download this bit file and in > the cmd , when i say ping fpga(mac address) and i start the ethereal > capture. I am able to see the data transfer to and from between fpga > and mac. > But if i dont ping it and just start capturing by clicking the capture, > i am not able to detect anything except the ARP which is data > transferred from PCs ip address to broadcast. > > In my project i dont ping in the cmd because i didnt include any ip > address in my vhdl code. So basically i am not able to detect anything > in the ethereal except the ARP which is being transferred from PC to > broadcast. The format of the ethernet frame i am using is > Destination MAC ad, Source MAC, length/type, data, FCS(CRC) and i am > not using any ip address or udp header in my ethernet frame in the vhdl > code. > > Probably the data is getting transferred on to the PC, but not able to > capture it since, i am not pinging it. So how do we see what data is > coming out from the PHY. > > Please advice ? > > Thanks > Ashwin >Article: 91872
Hi All, We've got a few Celoxica RC1000 FPGA boards that we'd like to use within a Linux environment. Has anyone had any luck compiling the drivers for a 2.6 kernel. The latest drivers I've been able to find (0.9.25) were written in 1998 and make use of a lot of deprecated header files. I'd love to hear if anyone has one working within an up-to-date linux environment. Many Thanks Andy -- Dr. Andrew Greensted Department of Electronics Bio-Inspired Engineering University of York, YO10 5DD, UK Tel: +44(0)1904 432379 Mailto: ajg112@ohm.york.ac.uk Fax: +44(0)1904 433224 Web: www.bioinspired.com/users/ajg112Article: 91873
Thus, if I want to inspect the internal of the FPGA I must use ChipScopePro with its load? Is there any other way to get informations about the flip-flops's status and other JTAG-ed components of the FPGA by the JTAG? Bye, Massimo. fad ha scritto: > I dont think you require anything else. For in circuit debugging.. all > you need is.. > 1) JTAG cable 2)ChipScope Pro 3)Impact for programming (which comes > with ISE only) > YOu need to have debuger like 'paradigm' through which you can do the > software verification of your IP. ChipScope is good enough to monitor > In-FPGA signals but puts a limitation on memory requirement. >Article: 91874
Hi, Thanks for answers. > 1) does the board worj when you use Avnet ref design image ? > There was no reference design for PCI included. But I believe board works. Everything else works fine. Currently I'm workin on some kind of PCI monitor, to see what is going on. > 2) the 24ma would not help, you have some problem with your core that > is the reason for the freeze > I think that is something with my core, too. I was asking about current, to be sure that electrical part of design is good. > and I suggest you start testing and analyzing some existing and > working PCI design before trying your own, and for your > own core make sure it works in testbench I've try to test my core with Altera'a testbench from their evaluation version of PCI compiler... But they set clk and data and everything else in the same time. How it could posible to sample data on rising clk, when data are set up in the same time? And they use adresses (in config read/write) with oldest bit set, why? Best regards Krzysztof Przednowek
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