OPENCORES.ORG

Hello and thanks for your reply!

Hi!
I have one suggestion - if your functional sim works, post P&R doesn't,
can you check if gate level - synthesized design without timing annotation
works.
If gate level functions, then it is probably timing related problem.
If it doesn't, then we'll have to investigate further ;)
And you are absolutely right - conf space access does not depend on RAM
instantiation
in any way.

Best regards,
Miha Dolenc

----- Original Message ----- 
From: "Mihelogiannakis giorgos" <mihelog@c...>
To: "Discussion list about free, open source PCI IP core"
<pci@o...>
Sent: Wednesday, March 16, 2005 10:34 PM
Subject: Re: [pci] FPGA Xilinx RAM Instantiation

> Hello and thanks for your reply!
>
>   The RAMB4_S16_S16 module i am using is the one included with Xilinx ISE
> 6.2.03i, and it's version is: 1.21.4.2 2003/12/05 00:34:0. If you supress
> the
> conflict warning messages by defining DISABLE_COLLISION_CHECK everything
> works fine and you don't even notice any difference. This means that the
> RAM instances work well, and don't go to an unknown state for infinity.
> However, this is in functional simulation only.
>
> Post PNR simulation suffers though. I am unsure whether the problem you
> were encountering occured in functional simulation, after synthesis or
> both, but in my case although functional simulation is healthy as ever,
>  post PNR simulation is not. The problem i am having is that during
> testing the initial configuration values (in test_initial_conf.v), the
> bridge never acks a read request in address x104. Right before this read
> request, a write request at the same address with data 10000000 was
> acknowledged. What's worrying is that (as i've seen) configuration space
> makes no use of these RAM instances, so i can come up with no explanation
> why this is happening. Unfortunately, i cannot generate this model with
> the original hierarchy, so debugging is close to impossible. In functional
> simulation, the read request the shows the problem, returns the data
> written right before. The behaviour before that read request, is the
> same./
>
> Before defining FPGA and XILINX (and thus instantiating any RAM modules)
> post PNR simulation was fine in all testcases. Is this any close to the
> problem you are referring to, and thus is fixed with an updated version of
> these RAMs? Do you have any other ideas?
>
> Thank you!
>    George Michelogiannakis
>
>
> On Wed, 16 Mar 2005, Miha Dolenc wrote:
>
> > Hi!
> >
> > The address conflict occurs every time the FIFO is empty and
> > something in written into it. This should not cause a problem,
> > since the data is not used until at least 2 read clock cycles after the
> > write.
> > I've once had similar problems with the RAM sim models as you are
> > describing.
> > I found out that the models were not working as they should and
> > when I replaced the models with a different version, everything started
> > working.
> > As I can see, your model reports that data on port B is unknown until
next
> > clk B.
> > That's expected and handled by the core.
> > The faulty models I've mentioned kept the data in the unknown state
> > indefenitely.
> > Can you check if that happens in your case?
> >
> > Best regards,
> > Miha Dolenc
> >
> > ----- Original Message -----
> > From: "Mihelogiannakis giorgos" <mihelog@c...>
> > To: <pci@o...>
> > Sent: Tuesday, March 15, 2005 10:39 PM
> > Subject: [pci] FPGA Xilinx RAM Instantiation
> >
> >
> >> Good day to everyone,
> >>       I have one quick question regarding instantiating FPGA RAM
instances
> >> to make the PCI bridge fully downloadable to an FPGA. I have defined
the
> >> "XILINX" and "FPGA" constants, which cause pci_wb_tram module to use
> >> Xilinx's RAMB4_S16_S16 to construct FIFO RAMs. If these two constants
are
> >> not defined, a generic RAM model is used instead, constructed from a
> >> couple of always@ blocks, and register arrays. The problem i am hacing
is
> >> that when these RAM instances are used, i get many conflict warning
> >> messages :
> >>
> >> # Memory Collision Error on
> >>
> >
RAMB4_S16_S16:SYSTEM.bridge32_top.bridge.wishbone_slave_unit.fifos.wbr_fifo_
> > storage.ramb4_s16_s16_1.display_zero
> >> at simulation time 456465.000 ns
> >> # A read was performed on address 0a (hex) of Port B while a write was
> >> requested to the same address on Port A. The write will be successful
> >> however the read value on Port B is unknown until the next CLKB cycle.
> >>
> >> Which refer to an address conflict on the RAM's two ports. As wired in
> >> pci_wbw_wbr_fifos.v, the read port of each RAM is always set to read
(chip
> >
> >> select and output enable are hardwired to 1) which would surely cause a
> >> problem at some point of the bridge's peration. The problem is that i
have
> >> tried changing the hardwiring from 1 to a condition whichcould
guarantee
> >> that  each instance is not written  and read at the same time, but
every
> >> change i've made either makes no difference, or causes the bridge to
> >> malfunction. This conflict is an address conflict, and occurs when the
> >> FIFO is empty and thus the two points (read and write) point to the
same
> >> address.
> >>
> >> With the conflicts, the functional code still works fine, but the
post-PNR
> >> simulation model does not. The simulation model works fine if the
gneric
> >> RAM instance is used (register arrays), but not if this conflict with
> >> other RAM instances are present.
> >>
> >> Has anyone else encountered this or a similar problem when
instantiating
> >> RAM instances for RAM? I would like to avoid generating a seperate RAM
> >> instance and therefore i would be most grateful for any help.
> >>
> >> Than kyou!
> >>    George Michelogiannakis
> >> _______________________________________________
> >> http://www.opencores.org/mailman/listinfo/pci
> >
> > _______________________________________________
> > http://www.opencores.org/mailman/listinfo/pci
> >
> _______________________________________________
> http://www.opencores.org/mailman/listinfo/pci