Electronics > Projects, Designs, and Technical Stuff
This is becoming quite a challenge, but I managed it.
<< < (5/6) > >>
xaxaxa:
I think XC6SLX9 remains the most cost effective FPGA at $5 each and 9000 LEs equivalent.

On a $99 product it doesn't make much sense to use a 2 layer board; the unit price of a 4 layer PCB is insignificant compared to the rest of the parts, and you get the advantage of a smaller board and less EMI emissions. I've even considered making a $20 product that uses a 4 layer board.
technix:

--- Quote from: xaxaxa on November 20, 2018, 01:44:09 am ---I think XC6SLX9 remains the most cost effective FPGA at $5 each and 9000 LEs equivalent.

--- End quote ---
I think so too. I won't be running a XC6SLX9 based Duplex though since I have my sights on Zynq.


--- Quote from: xaxaxa on November 20, 2018, 01:44:09 am ---On a $99 product it doesn't make much sense to use a 2 layer board; the unit price of a 4 layer PCB is insignificant compared to the rest of the parts, and you get the advantage of a smaller board and less EMI emissions. I've even considered making a $20 product that uses a 4 layer board.

--- End quote ---
At least on JLC's Chinese-facing pricing, 4-layer boards costs 2x as much as 2-layer boards at smaller quantities.
Bassman59:

--- Quote from: SiliconWizard on November 19, 2018, 05:50:37 pm ---
--- Quote from: technix on November 19, 2018, 05:09:43 am ---
--- Quote from: SiliconWizard on November 18, 2018, 11:13:01 pm ---I've grown to hate Actel parts and Libero even more.
But YMMV. ;D

--- End quote ---
Is there any reason for that?

--- End quote ---

From my experience with the Proasic3 line, they consistently tended to draw more power than expected and it was often a fight to meet timing constraints compared to other vendors' FPGAs in similar ranges. Usually switching to Xilinx or Lattice was an instant relief.
--- End quote ---

I am fighting that fight. 100 MHz is a challenge. There are a lot of things that trip you up. Some of it is because of what Synplify does, others are purely fabric-related. I have a list of things about the fabric that make it so. The lack of a CLB/LUT means you don't get free shift registers or small RAMs. The lack of a synchronous reset can make things like counter clears painful. There's no carry chain so "wide" adders and counters won't meet timing. Convincing the tools that those flip-flops need to be in the I/O is quite the challenge; instantiating them as DDR in and out flops seems to be the most reliable way to do so. Getting it to meet hold-time requirements on internal flops -- hold time! -- can be a challenge.

When something doesn't meet timing, it's worth looking to see what the synthesizer did with the code. In my current design I have to mux the outputs of sixteen 16-bit-wide block RAMs down to one 16-bit bus, and I had to pipeline the shit out of it because routing around the multiple 16:1 muxes never met timing. And then the tools decided that one of the mux selects was too heavily loaded so that line was put onto a global buffer -- and the routing to and from the global buffer (which is at the edge of the chip) made the timing worse!


--- Quote ---As for Libero, recent versions may have improved, but back when I was using it (few years ago), it was one of the most atrocious pieces of software I'd ever used ;D
Ultra slow, cumbersome, confusing...
--- End quote ---

I had to stop using the Libero project manager. Every time I updated my source it would decide to spin off a new "implementation," when meant a new Designer database. It hid too much from you, so you never quite knew what to do. So I run Synplify and the Designer place-and-route standalone.

Designer is stupid. When you create placement and timing constraints, they are buried in their big .adb file, which is the project database. You have to export them to text files (.sdc and .pdc) if you want to do something reasonable, like keep them in your source-code repository. And then when you change the text file and re-import it into the project, it wants to merge your new file with the existing constraints in the database. Who the hell knows exactly what has priority? So i just got into the habit of not checking those "merge" boxes. And then I noticed that sometimes nothing I did would make the design meet timing -- and it would grossly off from a previous run. I discovered that simply blowing away the .adb and creating a new Designer project gave me better results. (Thankfully creating the new Designer project is as simple as selecting the family and the directory in which the design will live, then selecting the exact part, then importing the EDN synthesis result, the PDC and the SDC, and letting it chug.) And when I let it run, I have to have the advanced options all on and let it do multiple placement attempts. It's ridiculous.

Oh, and good luck understanding the timing constraints, especially how to set up multi-cycle paths.


--- Quote ---programming with Actel "pods" was also nightmarishly slow as I recall.
--- End quote ---
We have a FlashPro 4 and a couple of FlashPro 5s here, and the 5 is much faster.

It's not all shit ... the Identify debugger, while not as slick as Xilinx' ChipScope, does work well enough, and doesn't kill timing (too much).
Araho:
Isn't it very sketchy to run FPGA I/O straight to headers on the board like that? First EMI-event happening (or hot-plugging a cable!) and you'll fry some of the input circuity, won't you?
james_s:
I have a bunch of FPGA boards with the IO run straight to the headers, never had any trouble at all. Some of them are little Cyclone II boards which are so cheap I never worried about it at all, I frequently toss one in my laptop bag without any ESD protection, and abuse it doing things like driving a speaker directly from IO pins. I've yet to kill one, they seem to be quite robust.

If it was a $500+ FPGA then I'd be a lot more careful but for cheap stuff? Whatever.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod