|
Message
From: Joel Rodriguez<joel@v...>
Date: Mon Aug 6 14:14:36 CEST 2007
Subject: [pci] pci_bridge32 on an Altera Cyclone II
Hi Jeremy,I been using the pci_bridge32 core in an Altera PCI dev-card
(Cyclone II EP2C35F672C6 based FPGA),
the BIOS successfully recognizes the board, I/O and memory
and configures the BAR's, everything looks ok
so far.
I'm using an efika (PPC based board, http://www.efika.de/index_en.html)
and successfully
manage to compile the test programs in /apps/test/rtl/verilog/* using
Gentoo and Jungo drivers
evaluation copy.
some tweaking required in clocks1_top_test.v
RAMB4_S16_S16.v
is required if you define in pci_user_constants.v
`define PCI_XILINX_RAMB4
`define WB_XILINX_RAMB4
......
`define PCI66
`define HEADER_DEVICE_ID 16'h0004
`define HEADER_REVISION_ID 8'h01
`define HEADER_VENDOR_ID 16'h1172
`define WB_RTY_CNT_MAX 8'hFF
`define PCI_WB_REV_B3
`define PCI_WBS_B3_RTY_DISABLE
`define PCI_MBIST_CTRL_WIDTH 3
`define WB_CONFIGURATION_BASE 12'h00_0
`define HEADER_SUBSYS_VENDOR_ID 16'h0000
`define HEADER_SUBSYS_ID 16'h0000
`define HEADER_MAX_LAT 8'h00
`define HEADER_MIN_GNT 8'h00
make an RAMB4_S16_S16.v with quartus mega Wizard (altsyncram function)
that looks like:
module RAMB4_S16_S16 (
data_a,
wren_a,
address_a,
data_b,
address_b,
wren_b,
clock_a,
enable_a,
clock_b,
enable_b,
aclr_a,
aclr_b,
q_a,
q_b);
input [15:0] data_a;
input wren_a;
input [7:0] address_a;
input [15:0] data_b;
input [7:0] address_b;
input wren_b;
input clock_a;
input enable_a;
input clock_b;
input enable_b;
input aclr_a;
input aclr_b;
output [15:0] q_a;
output [15:0] q_b;
wire [15:0] sub_wire0;
wire [15:0] sub_wire1;
wire [15:0] q_a = sub_wire0[15:0];
wire [15:0] q_b = sub_wire1[15:0];
altsyncram altsyncram_component (
.clocken0 (enable_a),
.clocken1 (enable_b),
.wren_a (wren_a),
.clock0 (clock_a),
.wren_b (wren_b),
.clock1 (clock_b),
.address_a (address_a),
.address_b (address_b),
.data_a (data_a),
.data_b (data_b),
.q_a (sub_wire0),
.q_b (sub_wire1),
.aclr0 (1'b0),
.aclr1 (1'b0),
.addressstall_a (1'b0),
.addressstall_b (1'b0),
.byteena_a (1'b1),
.byteena_b (1'b1),
.rden_b (1'b1));
defparam ......
endmodule
still, you should be able to get the card recognized, even with the
//`define PCI_XILINX_RAMB4
//`define WB_XILINX_RAMB4
(commented)
finally, the pin assignment is important, according to the board.
which dev-board are you using. I miss the Cyclone II FPGA spec.
regards,
Joel Rodriguez
ODM Technologies
Mira Mesa, CA
P.S. Miha thanks for such a wonderful core :).
Miha Dolenc wrote:
> Hi Jeremy!
>
> Infos look OK to me, as you have
> WISHBONE Slave interface's control signals
> tied off to zero, so PCI Master won't ever do any
> accesses and PCI Target never drives FRAME or
> IRDY.
>
> I'm puzzled why this doesn't work for you!
> I have only one idea left (it's a long shot though :)):
> Can it be, that device isn't shown at boot-up because
> BIOS doesn't recognize the vendor ID? Can you change
> it to the Altera's core one and try that?
> The only other course of action I can recommend from
> here on is simulation - just read vendor/device ID and
> configure BAR's. Then if this works, work through
> gate level and timing simulations - if it's not board
> problem, the thing should break at some point.
>
> Is there anyone on the list using the core in Altera to
> help us out? I know that at least a few people have used the core
> succesfully on Altera.
>
> Best regards,
> Miha Dolenc
>
> ----- Original Message ----- From: "Jeremy Hammer"
> <jeremyh@c...>
> To: "Discussion list about free, open source PCI IP core"
> <pci@o...>
> Sent: Friday, August 03, 2007 7:56 PM
> Subject: Re: [pci] pci_bridge32 on an Altera Cyclone II
>
>
>> Hi,
>>
>> I am going through the compile output and these lines are particularly
>> concerning to me.
>>
>> Info: Pin pci_framen has a permanently disabled output enable
>> Info: Pin pci_irdyn has a permanently disabled output enable
>>
>> Info: Pin pci_framen has VCC driving its datain port
>>
>> I am following the signals to their origin and they seem to be fine,
>> although it gets difficult to tell when you go in deep.
>>
>> Also, I put the PCI I/O assignments on and it didn't help. And yes I
>> found
>> the correct way to assign the PCI I/O assignments to the pins.
>>
>> What are your thoughts on the three "Info" lines from my compile?
>>
>> Thanks!
>> -Jeremy
>> _______________________________________________
>> http://www.opencores.org/mailman/listinfo/pci
>
> _______________________________________________
> http://www.opencores.org/mailman/listinfo/pci
>
|
 |
Browse
