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
MM wrote: > Hi Matthieu, > > Which OS are you running? Can you see the usage for all of the 4 cores when > you run MAP and/or PAR? I don't use EDK but I do use webpack 10.1.02. During map and par I can see it using two processors. I have a quad core system. Using fedora 8 and fedora 11. The following commands use the 2 processors :-xst, map, par, trce, netgen. Andy > > Thanks, > /Mikhail > >Article: 144251
"Andy Botterill" <andy@plymouth2.demon.co.uk> wrote in > > I don't use EDK but I do use webpack 10.1.02. During map and par I can see > it using two processors. I have a quad core system. Using fedora 8 and > fedora 11. > > The following commands use the 2 processors :-xst, map, par, trce, netgen. > Andy Thanks Andy. This is interesting. It seems to say that somehow OS(?) combines cores in pairs so that a 4 core system really looks as a 2 core system of which Xilinx uses only half... /MikhailArticle: 144252
On Nov 10, 3:48=A0am, Dave <doomedd...@yahoo.co.uk> wrote:
> Hi Group,
>
> In the past when I have wanted to use a script with ISE I have always
> simply run the flow using the gui first and then created a batch file
> using the command lines printed in the individual reports from xst,
> ngdbuild, etc. =A0Seemed to work quite well especially when using the
> errorlevel returns (in Windows) to catch errors.
>
> I am aware of the xflow system and that something can also no doubt be
> done using tcl and I am wondering what the "best" method is.
>
> What do you use and why?
>
> One key feature I want to include in the design I'm starting now is
> automatic build number increments by way of automatically increasing
> an integer generic supplied to XST. =A0This will be used to set the
> reset value of a register in the VHDL. =A0I am guessing a tcl script
> would be best for this but can this also be done using xflow?
>
> Many thanks for your time.
We perform most of our development on Linux workstations and execute
implementation using Make files. I haven't tried this method with EDK
projects yet, but will start on that very soon.
The method we use to generate a unique build name is to set a variable
in the make file and use that to name the output from the tools.
Example of a ripped apart make file:
# environmental
targets
buildDate=3D$(shell date +%m%d%y%H
%M)
buildStamp=3D$(shell date +%m%d%y
%H)
buildName=3Dfpga_$(buildDate)
ngdbuild $(ngdflags) ../fpga.edf $(buildName).ngd | tee -i pnr.log
map $(mapflags) -o $(buildName)_map.ncd $(buildName).ngd $
(buildName).pcf | tee -ai pnr.log
par $(parflags) $(buildName)_map.ncd $(buildName).ncd $(buildName).pcf
| tee -ai pnr.log
trce -e 3 -l 3 -xml $(buildName) $(buildName).ncd -o $(buildName).twr $
(buildName).pcf | tee -ai pnr.log
bitgen -f fpga.ut $(buildName).ncd | tee -ai pnr.log
Here's a method we've used to automagically modify a register setting
within the design. The original source includes a known register
value that gets modifed at the time the makefile is executed.
sed 's/ABCDEF00/$(buildStamp)/' ../path/to/source/
filewithVersionRegister.vhd > $(localTemp)/project
/path/to/source/filewithVersionRegister.vhd
We tend to have the make file copy all of the source to a build
directory and then move into that directory to execute the
implementation. That way we have a good record of source file
versions included with the build.
We'll see how well this process works with EDK, though.
Article: 144253Hello, We are working on a project to create a low cost Open Source Logic Analyzer. We are making great progress but would greatly appreciate any input from members of the comp.arch.fpga group. The design is based on the following resources: -Sump Logic Analyzer VHDL design. (http://www.sump.org/projects/ analyzer/) -Butterfly Light Hardware implementation. The goal is to streamline the Butterfly Light hardware to reduce costs. (http:// www.gadgetfactory.net/gf/project/lax/) If you have some time please take a look and give us you thoughts about the project. The design pages are: http://www.gadgetfactory.net/gf/project/butterflylogic/ All discussions about the project are located at: http://whereisian.com/forum/index.php?board=23.0 Thank you, Jack.Article: 144254
On Fri, 20 Nov 2009 16:09:04 -0500, MM wrote: > ISE/EDK11 has been crashing on me lately relentlessly complaining about > the lack of memory and just for no reason. I am considering moving to a > 64-bit OS just to eliminate the memory issue although I believe the root > of the problem is in the tools. Anyways, I was just wondering if the > latest EDK is indeed fully supported under 64-bit Linux as shown here > http://www.xilinx.com/ise/ossupport/index.htm? > > Thanks, > /Mikhail I use the EDK on a 64bit Ubuntu 9.10 and it works fine, no crashes yet... MaikArticle: 144255
To Martin and John: Adding "if rising_edge (bus2ip_clk) then" and specifying the IO standards solved the problem. Thanks! -Sean.Article: 144256
I'm working with a xilinx virtex 5 board (with the VLX110T) and have been
trying to get any kind of output to a DVI monitor. I'm using the IIC core
in XPS to try and program the CH7301. I'm using a clock generator to send a
25MHz clock to the xclk pin, sending a high value to the xclk*, and not
sending any of the 12 data bits because I'm assuming they aren't needed for
color bars...
I can talk to the CH7301 over the I2C bus and I'm not sure if I am
programming the control registers wrong or possibly my code is written
wrong and not programming them at all. Can anybody help me with this? The
code is below:
#define write_CH7301 0xEC //device address 0x76 shifted left 1 bit
/* Register Declarations */
#define GIE (*((volatile unsigned long*)(XPAR_IIC_BASEADDR + 0x01C)))
#define ISR (*((volatile unsigned long*)(XPAR_IIC_BASEADDR + 0x020)))
#define IER (*((volatile unsigned long*)(XPAR_IIC_BASEADDR + 0x028)))
#define SOFTR (*((volatile unsigned long*)(XPAR_IIC_BASEADDR + 0x040)))
#define CR (*((volatile unsigned long*)(XPAR_IIC_BASEADDR +
0x100)))
#define SR (*((volatile unsigned long*)(XPAR_IIC_BASEADDR +
0x104)))
#define TX_FIFO (*((volatile unsigned long*)(XPAR_IIC_BASEADDR +
0x108)))
#define RC_FIFO (*((volatile unsigned long*)(XPAR_IIC_BASEADDR +
0x10C)))
#define ADR (*((volatile unsigned long*)(XPAR_IIC_BASEADDR +
0x110)))
#define TX_FIFO_OCY (*((volatile unsigned long*)(XPAR_IIC_BASEADDR +
0x114)))
#define RC_FIFO_OCY (*((volatile unsigned long*)(XPAR_IIC_BASEADDR +
0x118)))
#define TEN_ADR (*((volatile unsigned long*)(XPAR_IIC_BASEADDR +
0x11C)))
#define RC_FIFO_PIRQ (*((volatile unsigned long*)(XPAR_IIC_BASEADDR +
0x120)))
#define GPO (*((volatile unsigned long*)(XPAR_IIC_BASEADDR +
0x124)))
void init_CH7301()
{
GIE = 0x80000000; //enable global interrupts for iic bus
IER = 0x4; //enable Tx FIFO Empty Interrupt [Int(2)]
CR = 0x01; //enable iic controller
/* IIC Master Transmitter with repeated START */
/* 1) Write IIC device @ to Tx_FIFO */
TX_FIFO = write_CH7301;
/* 2) Write data to Tx_FIFO */
TX_FIFO = 0x9C;
/* 3) Write to Control Register to set MSMS=1 and TX=1 */
CR = 0x0D; //TX, MSMS, EN = 1
/* 4) Continue writing data to Tx_FIFO */
TX_FIFO = 0x01;
/* 5) Wait for Transmit FIFO empty interrupt. */
while(!(ISR & 0x04)); //wait until TX_FIFO empty interrupt
/* 6) Write to CR to set RSTA=1 */
CR = 0x2D; //TX, MSMS, EN, RSTA = 1
/* 7) Write IIC device @ to Tx_FIFO */
TX_FIFO = write_CH7301;
/* 8) Write all data except last byte to Tx_FIFO */
TX_FIFO = 0x9F;
TX_FIFO = 0x84;
TX_FIFO = 0xEC;
TX_FIFO = 0xA1;
TX_FIFO = 0x0D;
TX_FIFO = 0xEC;
TX_FIFO = 0xC8;
TX_FIFO = 0x19;
TX_FIFO = 0xEC;
TX_FIFO = 0xC9;
TX_FIFO = 0xC0; //0x00 for bypass mode
TX_FIFO = 0xEC;
TX_FIFO = 0xD6;
/* 9) Wait for Transmit FIFO empty interrupt. */
while(!(ISR & 0x04)); //wait until TX_FIFO empty interrupt
/* 10) Write to CR to set MSMS=0. */
CR = 0x29; //RSTA, TX, EN = 1
/* 11) Write last byte of data to Tx_FIFO */
TX_FIFO = 0x01;
}
Article: 144257Hello, I have a PMC module that sits on a PCI-PMC adapter (adapter has some bus switches). I find that when the PCI card is plugged into one slot (slot 4) on the Motherboard the card is recognized by the "lspci" command under linux, however if the PCI card is plugged into another slot (slot 6, using same adapter as before) "lspci" does not recognize the PCI card. I have also found that if i transfer the PMC module to an adapter from an alternate vendor, the PCI card is now recognized in slot 6 also. What are the "primary" factors that could be causing this behavior ? Are there any key signals that have to be checked for signal integrity ? I have probed the board for IDSEL and it seems to be alright... Any help will be appreciated. Thanks in advance...Article: 144258
Hi,
I've been struggling in the past to generate such color bar test
patterns for both DVI and RGB mode and succeeded after some trial and
error loops. I'm not sure whether this setup can be stripped-down
furthermore, but it worked for me as a first "hello world" before
tackling the more complex topic of displaying an actual image.
The CH7301 required exact waveforms on the H, V & DE pins (I chose VGA
mode 0, 640x480), otherwise the display wouldn't sync. I went for
"sample 2x", i.e. XCLK and XCLK* toggle with 25 MHz, phase shifted by
180 deg. Guess proper XCLK/XCLK* clocking is essential to sample H, V
and DE.
I2C commands were applied according to AN-41, "Figure 4: Single Step
Writes". I.e. n times the sequence, SPC @ ~195 kHz:
1. START condition
2. DAB
3. RAB
4. Data
5. STOP condition
Didn't try auto increment write or similar.
My final settings for this testcase were
0 => (16#9C#, 16#00#), -- Clock Mode Register
1 => (16#9D#, 16#4C#), -- Input Clock Register: sample 2x
-- t_step XCLK behind of data
2 => (16#9F#, 16#80#), -- Input Data Format Register:
-- format #0, H low active, V low active
3 => (16#a1#, 16#00#), -- DAC Control Register:
-- disable HSYNC & VSYNC outputs
4 => (16#b3#, 16#08#), -- TPCP
5 => (16#b4#, 16#16#), -- TPD
6 => (16#b6#, 16#60#), -- TPF
7 => (16#c9#, 16#C0#), -- Power Management Register
-- DVI in normal function, RGB DACs off
8 => (16#c8#, 16#19#), -- TSTP: test pattern
Hope this helps & good luck!
Arnim
Article: 144259This kind of adapters violates PCI spec in several ways, resulting in that sometimes things don't work, especially at clock rates higher than 33 MHz. Also, if there are PCI-to-PCI bridges between the slots or on the adapter itself, there might be issues with resources not being properly assigned to the card by either BIOS or OS. Finally, PMC connectors are just not very good connectors, and I've seen more than a few cases where cleaning them with some contact cleaner resolved a problem. /Mikhail "Vikram Ragukumar" <vragukumar@signalogic.com> wrote in message news:Hu6dnauQqd1lVpfWnZ2dnUVZ_uidnZ2d@giganews.com... > Hello, > > I have a PMC module that sits on a PCI-PMC adapter (adapter has some bus > switches). I find that when the PCI card is plugged into one slot (slot 4) > on the Motherboard the card is recognized by the "lspci" command under > linux, however if the PCI card is plugged into another slot (slot 6, using > same adapter as before) "lspci" does not recognize the PCI card. > > I have also found that if i transfer the PMC module to an adapter from an > alternate vendor, the PCI card is now recognized in slot 6 also. > > What are the "primary" factors that could be causing this behavior ? Are > there any key signals that have to be checked for signal integrity ? I > have > probed the board for IDSEL and it seems to be alright... > > Any help will be appreciated. > > Thanks in advance... > >Article: 144260
Hello, I need to connect two Microblaze processors, each on a seperate Spartan 3e chip, but on the same board. Can this be done through FSL? Would it require two seperate projects in the XPS? Is there an example or tutorial on this subject?Article: 144261
jack.gassett <jack.gassett@gadgetfactory.net> wrote: > Hello, > We are working on a project to create a low cost Open Source Logic > Analyzer. We are making great progress but would greatly appreciate > any input from members of the comp.arch.fpga group. > The design is based on the following resources: > -Sump Logic Analyzer VHDL design. (http://www.sump.org/projects/ > analyzer/) > -Butterfly Light Hardware implementation. The goal is to streamline > the Butterfly Light hardware to reduce costs. (http:// > www.gadgetfactory.net/gf/project/lax/) > If you have some time please take a look and give us you thoughts > about the project. The design pages are: > http://www.gadgetfactory.net/gf/project/butterflylogic/ > All discussions about the project are located at: > http://whereisian.com/forum/index.php?board=23.0 Argh, registration required... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 144262
Thank you Mikhail.
To clarify, we have found that this adpater("bad adapter") works well in
several other servers. We are facing issues with a single slot on a single
server.
On examining further, we found that when the card is plugged into slot 6,
there is no clock signal. However, while using a different adapter, clock
signal is visible on the scope. PCI Slot 4 works perfectly with the "bad
adapter".
What does the PCI enumeration process look for so that it can quickly
(within very few cycles) decide if a device is present or not in a PCI slot
? Is there a register that we can access to force clock to be enabled to a
particular PCI slot ?
Thanks,
Vikram.
>This kind of adapters violates PCI spec in several ways, resulting in that
>sometimes things don't work, especially at clock rates higher than 33 MHz.
>Also, if there are PCI-to-PCI bridges between the slots or on the adapter
>itself, there might be issues with resources not being properly assigned
to
>the card by either BIOS or OS. Finally, PMC connectors are just not very
>good connectors, and I've seen more than a few cases where cleaning them
>with some contact cleaner resolved a problem.
>
>/Mikhail
>
>
>"Vikram Ragukumar" <vragukumar@signalogic.com> wrote in message
>news:Hu6dnauQqd1lVpfWnZ2dnUVZ_uidnZ2d@giganews.com...
>> Hello,
>>
>> I have a PMC module that sits on a PCI-PMC adapter (adapter has some
bus
>> switches). I find that when the PCI card is plugged into one slot (slot
4)
>> on the Motherboard the card is recognized by the "lspci" command under
>> linux, however if the PCI card is plugged into another slot (slot 6,
using
>> same adapter as before) "lspci" does not recognize the PCI card.
>>
>> I have also found that if i transfer the PMC module to an adapter from
an
>> alternate vendor, the PCI card is now recognized in slot 6 also.
>>
>> What are the "primary" factors that could be causing this behavior ?
Are
>> there any key signals that have to be checked for signal integrity ? I
>> have
>> probed the board for IDSEL and it seems to be alright...
>>
>> Any help will be appreciated.
>>
>> Thanks in advance...
>>
>>
>
>
>
---------------------------------------
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com
Article: 144263
Thank you Mikhail.
To clarify, we have found that this adpater("bad adapter") works well in
several other servers. We are facing issues with a single slot on a single
server.
On examining further, we found that when the card is plugged into slot 6,
there is no clock signal. However, while using a different adapter, clock
signal is visible on the scope. PCI Slot 4 works perfectly with the "bad
adapter".
What does the PCI enumeration process look for so that it can quickly
(within very few cycles) decide if a device is present or not in a PCI slot
? Is there a register that we can access to force clock to be enabled to a
particular PCI slot ?
Thanks,
Vikram.
>This kind of adapters violates PCI spec in several ways, resulting in that
>sometimes things don't work, especially at clock rates higher than 33 MHz.
>Also, if there are PCI-to-PCI bridges between the slots or on the adapter
>itself, there might be issues with resources not being properly assigned
to
>the card by either BIOS or OS. Finally, PMC connectors are just not very
>good connectors, and I've seen more than a few cases where cleaning them
>with some contact cleaner resolved a problem.
>
>/Mikhail
>
>
>"Vikram Ragukumar" <vragukumar@signalogic.com> wrote in message
>news:Hu6dnauQqd1lVpfWnZ2dnUVZ_uidnZ2d@giganews.com...
>> Hello,
>>
>> I have a PMC module that sits on a PCI-PMC adapter (adapter has some
bus
>> switches). I find that when the PCI card is plugged into one slot (slot
4)
>> on the Motherboard the card is recognized by the "lspci" command under
>> linux, however if the PCI card is plugged into another slot (slot 6,
using
>> same adapter as before) "lspci" does not recognize the PCI card.
>>
>> I have also found that if i transfer the PMC module to an adapter from
an
>> alternate vendor, the PCI card is now recognized in slot 6 also.
>>
>> What are the "primary" factors that could be causing this behavior ?
Are
>> there any key signals that have to be checked for signal integrity ? I
>> have
>> probed the board for IDSEL and it seems to be alright...
>>
>> Any help will be appreciated.
>>
>> Thanks in advance...
>>
>>
>
>
>
---------------------------------------
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com
Article: 144264"Vikram Ragukumar" <vragukumar@signalogic.com> writes: >Hello, >I have a PMC module that sits on a PCI-PMC adapter (adapter has some bus >switches). I find that when the PCI card is plugged into one slot (slot 4) >on the Motherboard the card is recognized by the "lspci" command under >linux, however if the PCI card is plugged into another slot (slot 6, using >same adapter as before) "lspci" does not recognize the PCI card. >I have also found that if i transfer the PMC module to an adapter from an >alternate vendor, the PCI card is now recognized in slot 6 also. >What are the "primary" factors that could be causing this behavior ? Are >there any key signals that have to be checked for signal integrity ? I have >probed the board for IDSEL and it seems to be alright... >Any help will be appreciated. >Thanks in advance... On an FPGA web site recently I found a link to an open source PCI enumerating program and thought I had marked where to get it. Of course I can't now find the reference :-). With luck someone else here will know of the program and provide a reference (or I may yet find where I noted it ...) Peter Van EppArticle: 144265
a, How do you want to connect them? What do you want to do? You could place a gpio block on each one's bus, and bring these general purpose IO's out to a connector, and cross connect them. Now you can use IO read/write mapped to the to gpio communicate. Or, you could bring out the entire bus, after you convert it to a PLB bus, and cross connect the two PLB buses: now you have two masters, and you have to figure out how not to have them collide (a shared memory system?). Or, you could design your own interface, with back to back FSL (fast simplex links), and then bring the FSL ports to IO pins so you may connect them. Or, you could use the Ethernet soft MAC core to couple to boards using gigabit ethernet using TCP/IP. Or, you could use the Aurora core, Or.... The list is pretty endless. It is called "computer networking" and it is a study at least 40 years old. AustinArticle: 144266
Could somebody explain what the BIOS uses to determine if a PCI slot is
vacant ? Is there something bad that is happening to one of these important
signals that causes the BIOS to think that the PCI card is non-existant ?
Thanks...
>Thank you Mikhail.
>
>To clarify, we have found that this adpater("bad adapter") works well in
>several other servers. We are facing issues with a single slot on a
single
>server.
>
>On examining further, we found that when the card is plugged into slot 6,
>there is no clock signal. However, while using a different adapter, clock
>signal is visible on the scope. PCI Slot 4 works perfectly with the "bad
>adapter".
>
>What does the PCI enumeration process look for so that it can quickly
>(within very few cycles) decide if a device is present or not in a PCI
slot
>? Is there a register that we can access to force clock to be enabled to
a
>particular PCI slot ?
>
>Thanks,
>Vikram.
>
>>This kind of adapters violates PCI spec in several ways, resulting in
that
>
>>sometimes things don't work, especially at clock rates higher than 33
MHz.
>
>>Also, if there are PCI-to-PCI bridges between the slots or on the
adapter
>
>>itself, there might be issues with resources not being properly assigned
>to
>>the card by either BIOS or OS. Finally, PMC connectors are just not very
>>good connectors, and I've seen more than a few cases where cleaning them
>>with some contact cleaner resolved a problem.
>>
>>/Mikhail
>>
>>
>>"Vikram Ragukumar" <vragukumar@signalogic.com> wrote in message
>>news:Hu6dnauQqd1lVpfWnZ2dnUVZ_uidnZ2d@giganews.com...
>>> Hello,
>>>
>>> I have a PMC module that sits on a PCI-PMC adapter (adapter has some
>bus
>>> switches). I find that when the PCI card is plugged into one slot
(slot
>4)
>>> on the Motherboard the card is recognized by the "lspci" command under
>>> linux, however if the PCI card is plugged into another slot (slot 6,
>using
>>> same adapter as before) "lspci" does not recognize the PCI card.
>>>
>>> I have also found that if i transfer the PMC module to an adapter from
>an
>>> alternate vendor, the PCI card is now recognized in slot 6 also.
>>>
>>> What are the "primary" factors that could be causing this behavior ?
>Are
>>> there any key signals that have to be checked for signal integrity ? I
>>> have
>>> probed the board for IDSEL and it seems to be alright...
>>>
>>> Any help will be appreciated.
>>>
>>> Thanks in advance...
>>>
>>>
>>
>>
>>
>
>---------------------------------------
>This message was sent using the comp.arch.fpga web interface on
>http://www.FPGARelated.com
>
---------------------------------------
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com
Article: 144267
There are 2 main ways that a card is found. On a conventional PCI card
there are 2 presence lines that can indicate a card is there and give
some other information about the card. Not all formats of PCI have
this capability and some Bios's don't use them either even if there.
The other way is straightforward try the slot approach where a cycle
is attempted to see if there is a response.
IDSEL lines are usually derived off one of the upper address lines.
The config commands are used in conjuction with a given IDSEL to
select up a card for configuration.
Some of PCI timings are very tight even at 33MHz and adding either
track length or capacitence can mean you don't meet timing.
John Adair
Enterpoint Ltd.
On 23 Nov, 21:53, "Vikram Ragukumar" <vraguku...@signalogic.com>
wrote:
> Thank you Mikhail.
>
> To clarify, we have found that this adpater("bad adapter") works well in
> several other servers. We are facing issues with a single slot on a singl=
e
> server.
>
> On examining further, we found that when the card is plugged into slot 6,
> there is no clock signal. However, while using a different adapter, clock
> signal is visible on the scope. PCI Slot 4 works perfectly with the "bad
> adapter".
>
> What does the PCI enumeration process look for so that it can quickly
> (within very few cycles) decide if a device is present or not in a PCI sl=
ot
> ? Is there a register that we can access to force clock to be enabled to =
a
> particular PCI slot ?
>
> Thanks,
> Vikram.
>
>
>
>
>
> >This kind of adapters violates PCI spec in several ways, resulting in th=
at
> >sometimes things don't work, especially at clock rates higher than 33 MH=
z.
> >Also, if there are PCI-to-PCI bridges between the slots or on the adapte=
r
> >itself, there might be issues with resources not being properly assigned
> to
> >the card by either BIOS or OS. Finally, PMC connectors are just not very
> >good connectors, and I've seen more than a few cases where cleaning them
> >with some contact cleaner resolved a problem.
>
> >/Mikhail
>
> >"Vikram Ragukumar" <vraguku...@signalogic.com> wrote in message
> >news:Hu6dnauQqd1lVpfWnZ2dnUVZ_uidnZ2d@giganews.com...
> >> Hello,
>
> >> I have a PMC module that sits on a PCI-PMC adapter (adapter has some
> bus
> >> switches). I find that when the PCI card is plugged into one slot (slo=
t
> 4)
> >> on the Motherboard the card is recognized by the "lspci" command under
> >> linux, however if the PCI card is plugged into another slot (slot 6,
> using
> >> same adapter as before) "lspci" does not recognize the PCI card.
>
> >> I have also found that if i transfer the PMC module to an adapter from
> an
> >> alternate vendor, the PCI card is now recognized in slot 6 also.
>
> >> What are the "primary" factors that could be causing this behavior ?
> Are
> >> there any key signals that have to be checked for signal integrity ? I
> >> have
> >> probed the board for IDSEL and it seems to be alright...
>
> >> Any help will be appreciated.
>
> >> Thanks in advance...
>
> --------------------------------------- =A0 =A0 =A0 =A0
> This message was sent using the comp.arch.fpga web interface onhttp://www=
.FPGARelated.com
Article: 144268"Vikram Ragukumar" <vragukumar@signalogic.com> wrote in message news:i6idnR-E1KSjmZbWnZ2dnUVZ_gmdnZ2d@giganews.com... > > What does the PCI enumeration process look for so that it can quickly > (within very few cycles) decide if a device is present or not in a PCI > slot > ? Is there a register that we can access to force clock to be enabled to a > particular PCI slot ? > The system is supposed read the device's configuration space using special configuration read cycles. I am not sure why different adapters would behave differently, but if your PCI interface is implemented in an FPGA (I am guessing since you are posting in comp.arch.fpga), it might be simply not ready by the time the system is trying to read it... This is a well-known problem with FPGA PCI implementation. I believe the fix is to somehow delay the PCI bus polling at the boot time. Another possible reason for not enabling the slot is if the system cannot allocate enough resources (usually memory or IO space is the problem) to the card. The card might be requesting too much or a PCI-to-PCI bridge if present might have too small a window... You could also check the CMOS settings for the system to see if there is something PCI related that you can disable... I believe choosing Plug&Play OS forces OS to assign PCI resources instead of BIOS. Sometimes disabling this feature helps... Sorry, it's been a while since I was actively involved in PCI development, so my memory is a little rusty... /MikhailArticle: 144269
>The CH7301 required exact waveforms on the H, V & DE pins (I chose VGA >mode 0, 640x480), otherwise the display wouldn't sync. I went for >"sample 2x", i.e. XCLK and XCLK* toggle with 25 MHz, phase shifted by >180 deg. Guess proper XCLK/XCLK* clocking is essential to sample H, V >and DE. Does "VGA mode 0" refer to the IDF bits? Also, did you just choose 25MHz randomly because it was less than 36MHz as Table 2: DVI Outputs in the CH7301 datasheet says? >I2C commands were applied according to AN-41, "Figure 4: Single Step >Writes". I.e. n times the sequence, SPC @ ~195 kHz: Was 195Khz a random choice of speed as well? >My final settings for this testcase were > 0 => (16#9C#, 16#00#), -- Clock Mode Register > 1 => (16#9D#, 16#4C#), -- Input Clock Register: sample 2x > -- t_step XCLK behind of data > 2 => (16#9F#, 16#80#), -- Input Data Format Register: > -- format #0, H low active, V low active > 3 => (16#a1#, 16#00#), -- DAC Control Register: > -- disable HSYNC & VSYNC outputs > 4 => (16#b3#, 16#08#), -- TPCP > 5 => (16#b4#, 16#16#), -- TPD > 6 => (16#b6#, 16#60#), -- TPF > 7 => (16#c9#, 16#C0#), -- Power Management Register > -- DVI in normal function, RGB DACs off > 8 => (16#c8#, 16#19#), -- TSTP: test pattern Did you have to write custom VHDL to do the timings for the V and H pins? Did you use the 25MHz clock you chose above and the chosen resolution of 640x480 to determine the H and V input lines? Does having the H and V active low mean that the "active time" for outputting RGB values is when you drop these signal lines? I know there are lots of questions here and thanks for your help so far, I don't know why there isn't better documentation for implementing this chip... --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144270
On Nov 23, 6:47=A0am, "maxascent" <maxasc...@yahoo.co.uk> wrote: > I am looking at using the ISERDES block in a V5 design for a DDR2 > controller. I want to input the DQ into an IODELAY block and then into th= e > ISERDES. Problem is I am not sure that you can do this anymore. I have se= en > some old app notes with this configuration and a DDLY input on the ISERDE= S. > But the new user guides dont have this input and they call the ISERDES a > NODELAY block. Does anyone know anymore info regarding this? > > Jon =A0 =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > This message was sent using the comp.arch.fpga web interface onhttp://www= .FPGARelated.com There are some race conditions associated with DDR2 and ISERDES IIRC. Wh dont you use the Memory Interface Generator (MIG) in coregen?Article: 144271
On Nov 20, 4:56 am, Vaughn <vaughnb...@gmail.com> wrote: > On Nov 17, 8:10 pm, d_s_klein <d_s_kl...@yahoo.com> wrote: > > > > > On Nov 14, 3:18 pm, Michael S <already5cho...@yahoo.com> wrote: > > > > Hi > > > We have a problem with Altera Stratix IV GX FPGA Development Kit. > > > Specifically, we build a PCI Express design based on Altera's own > > > "hard" PCI-E core configured for Gen.1 x4 operation. The design works > > > (more or less, but that's behind the scope of this message) when it i= s > > > plugged into x8 mechanical/x4 electrical slot. However when plugged i= n > > > x8 or x16 mechanical slots which are electrically x8 the design not > > > only doesn't work but not even recognized by the host as valid PCI-E > > > device. Exactly the same happens when we are trying to build x1 > > > device. > > > We validated (by plugging off-the-shelf x1 and x4 PCI-E cards) that > > > it's not a host issue. > > > My only PCI-E book (Mindshare "PCI Express System Architecture") tell= s > > > virtually nothing about width negotiation so right now I am totally > > > lost. > > > > Any ideas to help? > > I talked to two of our PCIe experts, and they suggested checking three > things: > > The DIP switch that controls how many lanes are supported via the PCIe > connector presence detect settings could be set wrong. It is SW5 on > the board, see table 2-15 in the board reference manualhttp://www.altera.= com/literature/manual/rm_sivgx_fpga_dev_board.pdf. > DIP switch appears to have no effect at all. That is, I can set it into x1-only position and host/board still sometimes negotiate to x4. Or I can set it to x1+x4+x8 and it sometimes correctly detects x4. the key word here - sometimes. BTW, what are those presence detects? What are they supposed to do? Is it something dev-kit specific, Altera-specific or standard? > If it is an Intel motherboard in some cases they send out Vendor > Defined messages. The customer=92s application design needs to be > designed to ignore these messages (unless the customer is Intel then > their application might need to know what these messages are and do > the right thing). If the application design doesn=92t accept these > messages from the core it will lock things up and cause configuration > problems. > Yes, it is an Intel board - brand new S3420GPLC. I also tested on the other Intel board - 4 years desktop based on 915-series chipset. It misbehaves in a similar manner. With a bit of effort I could find some Dell or Asus or may be Supermicro to test but all of them are based on Intel chipsets so it probably wouldn't make difference. Finding testing platform not based on Intel chipset would present a serious challenge. Besides, even if I'd find one - it's not going to help since it _has_ to work on Intel at the end. So tell me more about how exactly my application could ignore Vendor Defined messages. Please keep in mind that I am using Avalon-MM variant of the PCIe core so I don't have too much control on what's going on under the hood. One more point - with soft PCIe IP it misbehaves slightly less (and differently) than with hard IP but misbehave nevertheless. BTW, even in the slot which is x4 electrically things are not rosy. Quite often in that slot board is detected as x1 or x2 instead of x4. When detected as x2 it tends to not work at all, when detected as x1 it behaves better (not good, just better). Anyway I _need_ x4. Were I wanted x1 I'd rather build from cheap PLX bridge + cheap StartixIII - combo that "just works". > If you have Engineering Sample (not production) silicon, it could be a > case of the Stratix IV GX ES erratum entitled =93Endpoints Using the > Hard IP Implementation Incorrectly Handle CfgRd0=94 as described in the > IP Release notes:http://www.altera.com/literature/rn/rn_ip.pdf. > Workaround for this is to use production devices or use soft IP (v9.0 > or later) on ES devices. How do I know whether it is Engineering Sample or production device? > > Hope this helps, Yes, it does, thanks. But more help needed. In fact I am starting to suspect that the kit we have is physically damaged. Would be real shame if it is the case - so much time already wasted, but better that than not finding solution at all. > > Vaughn Betz > Altera > [v b e t z (at) altera.com]Article: 144272
On Nov 20, 4:56 am, Vaughn <vaughnb...@gmail.com> wrote: > On Nov 17, 8:10 pm, d_s_klein <d_s_kl...@yahoo.com> wrote: > > > Hope this helps, > > Vaughn Betz > Altera > [v b e t z (at) altera.com] If we are talking already - one more question, may be related or may be not. I measured PCIe read latency from host to zero-latency avalon-mm slave that lives in pcie_clock_out clock domain. To my big surprise the latency was absolutely huge - around 1050 ns for hard IP and 880 ns for soft IP. I expected much shorter latency - 250 ns, at wost 300. The measurements were done in the PCIe slot directly attached to Xeon 3400 CPU so from the host perspective it's probably the fastest configuration in current existence. Why is read so slow? Is it (hopefully) an another sign of hardware problem? Or is Altera ST-to-MM converter so slow (I find it hard to believe, according to my estimate that particular part of the loop should contribute about 50 ns, if not less)? Or Altera PCIe IPs themselves are poorly suited for serving host read access?Article: 144273
vanepp@sfu.ca (Peter Van Epp) writes: <snip> > On an FPGA web site recently I found a link to an open source PCI >enumerating program and thought I had marked where to get it. Of course I >can't now find the reference :-). With luck someone else here will know of >the program and provide a reference (or I may yet find where I noted it ...) Found the site: http://members.datafast.net.au/dft0802/ while I haven't gotten far enough yet to need to use it it may help you. As well in the documentation that came with my Dragon board there is some advise on PCI problems: http://www.knjn.com/docs/KNJN%20PCI%20Dragon%20board.pdf section 6.4 which describes the clock signal being disabled by BIOS when there is no PCI configuration space implemented. The no clock signal sounds like what you have. Hope one of these helps :-) Peter Van Epp Peter Van EppArticle: 144274
What kind of race conditions? MIG is ok but I would rather have my own so I can be sure what its doing. Jon --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.com
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