Advice on Xilinx Spelunking
in [FPGA]
|
Prev: mux behavior
Next: Software bloat (Larkin was right)
From: Nial Stewart on 26 May 2010 12:39 > The reset logic was sequential, i.e. reset address 0, then reset address 1, one per clock until > the entire thing was done. The intention being that the entire thing would take place on the > normal write port of the RAM, which wasn't being used while it was in the reset state. Apparently > it didn't work out that way. Oh right, that's odd. I wonder if the ram inference and reset were too tightly integrated for the synthesis tool to extract the RAM? Taking the reset functionality out made its job easier. Nial.
From: Darol Klawetter on 26 May 2010 12:43 On May 26, 11:05 am, Rob Gaddi <rga...(a)technologyhighland.com> wrote: > On 5/26/2010 1:54 AM, Nial Stewart wrote: > > >> It turns out that, if I just comment out the reset logic, the utilization drops to 236 LUTs. It > >> must have been implementing something truly awful to try to get that extra write port in. Why it > >> thought it needed it in the first place I'll never know, but at least I'm back on track now. > > > Rob, some(/most) templates for inferring RAMs don't work if you have a > > reset defined. > > > Nial. > > The reset logic was sequential, i.e. reset address 0, then reset address > 1, one per clock until the entire thing was done. The intention being > that the entire thing would take place on the normal write port of the > RAM, which wasn't being used while it was in the reset state. > Apparently it didn't work out that way. > > -- > Rob Gaddi, Highland Technology > Email address is currently out of order Rob, In the the report generated by the Xilinx map application, see "Section 14 - Utilization by Hierarchy." This will give you a hierarchical resource breakdown (including LUTs), though it may not have the detail your after. Darol Klawetter
From: rickman on 27 May 2010 14:05 On May 26, 12:39 pm, "Nial Stewart" <nial*REMOVE_TH...(a)nialstewartdevelopments.co.uk> wrote: > > The reset logic was sequential, i.e. reset address 0, then reset address 1, one per clock until > > the entire thing was done. The intention being that the entire thing would take place on the > > normal write port of the RAM, which wasn't being used while it was in the reset state. Apparently > > it didn't work out that way. > > Oh right, that's odd. > > I wonder if the ram inference and reset were too tightly integrated for > the synthesis tool to extract the RAM? Taking the reset functionality > out made its job easier. > > Nial. How can a sync ram be used at all if an async reset is specified in the HDL? There is no way to "add" an async reset to a sync memory. Rick
From: John_H on 28 May 2010 06:32 On May 27, 2:05 pm, rickman <gnu...(a)gmail.com> wrote: > > How can a sync ram be used at all if an async reset is specified in > the HDL? There is no way to "add" an async reset to a sync memory. > > Rick From the original poster 2 messages before yours: "The reset logic was sequential, i.e. reset address 0, then reset address 1, one per clock until the entire thing was done." Nothing asynchronous here.
From: rickman on 28 May 2010 13:17
On May 28, 6:32 am, John_H <newsgr...(a)johnhandwork.com> wrote: > On May 27, 2:05 pm, rickman <gnu...(a)gmail.com> wrote: > > > > > How can a sync ram be used at all if an async reset is specified in > > the HDL? There is no way to "add" an async reset to a sync memory. > > > Rick > > From the original poster 2 messages before yours: "The reset logic was > sequential, i.e. reset address 0, then reset address > 1, one per clock until the entire thing was done." Nothing > asynchronous here. That shouldn't prevent a memory from being used then. That's just logic driving the RAM. I would guess there was something about the code that couldn't be done with a ram. Actually, looking at his code, I don't see where he is writing to the ram ram_dat. fir_cascade is written, but I don't see where it is initialized. I don't get his code. It looks more like software than hardware. I'm used to debugging hardware... Rick |