|
taqueso posted:I saw a blurb on Migen in the opencores newsletter. Looks pretty neat, but I haven't really dug into it yet. Looking forward to asking Sebastien about that when I see him in a few months at Notacon (he's doing a talk on Milkymist there). I don't think I would see myself using it at work though...debugging and simulation is already kludgey enough as it is, I don't think I'd want to add another layer in there. We have a Cadence Incisive license at the moment that we use for simulation. I thought the DDS IP that was mentioned in the newsletter looks pretty slick. Not to mention their reminder that 28nm FPGAs are finally going mass-market. I was tired of fellating the FAEs to get samples. e: then again, OpenCores is also full of gems like USB 3.0 Device and Hose IP Core. 
movax fucked around with this message at 05:53 on Feb 28, 2012 |
#
¿
Feb 28, 2012 05:50
|
|
|
|
| # ¿ May 24, 2024 20:09 |
|
|
This is kind of the FPGA thread. Anyone had a change to play with PCIe 3.0 IP from Xilinx or Altera?
|
|
#
¿
Apr 11, 2012 06:29
|
|
|
JawnV6 posted:
For some reason I misremembered the presentation I got from the sales reps as the mid-range models getting PCIe 3.0 as well, but it's just the Stratix V and Virtex 7 that sport Gen 3.0 support. (So, huge bucks.) Every Xilinx 7-series member at worst has Gen 2 PCIe (for some reason I thought Kintex-7 had Gen3). The Cyclone IV GX is currently pretty "cheap", but only does Gen1 PCIe.
|
|
#
¿
Apr 12, 2012 05:53
|
|
Full speed gen3? What FPGA has 8GT/s IOs?
|
taqueso posted:Are there any FPGAs that have PCIe 1.1 compliant IOs and available IP that are not in a BGA package? I'd like to be able to hand solder these if it is possible. The Cyclone IV GX TQFP *might*, it can do USB, IIRC. I'd assume the inductance of the TQFP lead itself severely curtails high speed protocols.
|
|
#
¿
Apr 12, 2012 17:28
|
|
|
Quartus II 12.0 came out a little bit ago. I'm seeing improvement in synthesis time (knocked a ~20 minute project down to 15 minute) and does a better job on timing (Fmax increased a bit). Of course, the device packs for 12.0 add support for all the new 28nm hotness. Anyone else play with it?
|
|
#
¿
Jul 13, 2012 00:43
|
|
|
Today I learned/confirmed that programming files spit out of Quartus II >= 12.0 are intended to be unusable with older versions of the programming software! We use JICs mostly, so my search queries failed to turn up anything on Altera KB until finally I made it broad enough to find this! quote:No, programming files for use with AS mode generated in the Quartus® II software versions 12.0 and later will not be compatible with the Quartus II programmer versions 11.1sp2 and older. Maybe this will save someone 20 minutes  e: the older versions will claim that the file is corrupt 
|
|
#
¿
Oct 9, 2012 16:58
|
|
|
For the amount of money Cadence charges for their stuff, they should loving send out a dude to install and set all the poo poo up instead of a 'doc' directory full of scatted docs  Ugggh. e: also I think they rename their poo poo every few years just to keep people guessing so you end up with docs that refer to the same product under like four different names, going all the way back to the original vendor before Cadence bought them (there are still references to Verisity in Incisive eight years later). Send their marketing team into the sun. movax fucked around with this message at 00:04 on Jan 12, 2013 |
|
#
¿
Jan 12, 2013 00:01
|
|
|
JawnV6 posted:Woops, yup, that's where my head was. Sorry about that! That's pretty slick looking, I've always wanted to play with HDMI some more. For a similar price, you can get a Zynq dev-board as well. I've been having a lot of fun (I guess that's the word) working with the SoC FPGAs from Xilinx and Altera (mostly Xilinx since I can actually get the silicon). Excellent Linux software support, hard Cortex-A9s + memory controller + peripherals + Kintex-derived logic fabric is pretty awesome. You've got a myriad of AXI ports and crossbar switches serving as the interface between PL and PS, so its crazy easy to strap your custom logic to Linux applications with some simple glue logic + a kernel driver. Just finished doing some housekeeping at work in terms of getting a simulation environment stable and running after our last simulation machine bit the dust...learned more recently than I ever wanted to know about vendor-specific sim libs + Cadence tools. Anyone using Mentor or Synopsys' simulation solutions? We're thinking about looking elsewhere come the new fiscal year to save some money since it seems like everyone is cheaper than Cadence.
|
|
#
¿
Feb 7, 2013 06:58
|
|
|
Delta-Wye posted:FWIW, the first few times I sat down and worked in VHDL or Verilog it was a bit of a mindfuck. I'm not surprised to see that there are a lot of people who sit down and expect their higher language skills and techniques to translate over to what, from the outside, just appears to be a different programming language. It took me a few weeks of trying different things to finally get the "describing hardware, not writing code" mindset. Yeah, I can definitely see that. Lot of good programmers got their poo poo rocked in my intro HDL class because they couldn't wrap their heads around the concept of describing hardware vs. writing programs. Question: anyone using Mentor QuestaSim as their verification platform? We're thinking about moving to that from Cadence as we could actually buy it outright for what we rent/license Cadence yearly for.
|
|
#
¿
Feb 18, 2013 06:07
|
|
|
SnoPuppy posted:That...doesn't make any sense. The guy behind MilkyMist (some kind of music/video synth IIRC) was working on a solution that let you use Python to generate HDL; it was actually quite a bit further along than you'd expect from an average FOSS project.
|
|
#
¿
Mar 30, 2013 07:37
|
|
|
Serious question: has anyone made any appreciable effort / attempt at implementing H.264/VC-1/DD/etc decoding openly/non-commercially in HDL? Just idly curious because in the software world obviously its a bit easier, but projects like ffmpeg/libavcodec/etc have done that. I was entertaining notions of using a Zynq SOC as the core for a STB; twin Cortex-A9s and then theoretically you could implement any new and upcoming formats in HDL, and not go obsolete for a long-rear end time.
|
|
#
¿
Apr 1, 2013 18:13
|
|
|
Double-post but I'm pretty sure I just made an intern cry by fixing the problem he had with simulation for a good week by switching to VHDL-1993 from VHDL-2002 in about five seconds. There was just this look on his face of...I don't know, horror, resignation or just plain collapse at realizing that yes, different source files from different vendors may need to be compiled against different versions of the LRM. VHDL 
|
|
#
¿
Apr 2, 2013 22:30
|
|
|
Anyone try to stuff their Verilog into 80 columns also? Literally made an extra assign statement just to get some stuff to fit in 80 columns; no real negative effect on the synthesis, just seems kinda silly is all.
|
|
#
¿
May 24, 2013 01:24
|
|
|
Malcolm XML posted:Got a link ? Would be interested in joining you. I googled it, looks like unless I missed something, registration is closed / class slides & materials aren't shared directly. Zynq and Cyclone V are both great ideas; Cyclone V is nowhere near ready (I would honestly say it is a good year at the least behind Zynq, and I'm an Altera fan) though. Zynq has a lot of little details you have to get right (by repeatedly reading the docs) but it's shipping now/very soon, and Xilinx is using it as a good excuse to clean up their development tools. We're using Zynq as the core of our new product, and it's really the only thing enabling us to meet a lot of targets simply because we can do our own hardware (critical for this application, lots of hardware control loops + acquisition) and port our existing Linux software over to the exact same piece of silicon, all with a stupidly low TDP that lets us run at 50C+ without a fan. Hopefully Zynq sells well and Xilinx will upgrade the PS (ARM) half of the equation fairly frequently; the A9 sadly suffers from memory performance issues (like half the smartphone/tablet market running A9s right now). Xilinx also seems to be ahead of the game when it comes to kernel support; they're stupidly fast when it comes to matching mainline. Altera had one thing going for them which was cost, but after the inability for them to deliver dev kits + an apparent lack of support in Quartus (even Beta 13), we switched to Xilinx. Get your poo poo together guys 
|
|
#
¿
May 29, 2013 22:50
|
|
|
Malcolm XML posted:Man all I want is to make the beeps and the boops and everything has to get in the way. All EDA tools are terrible with terrible UIs because who the gently caress else's tools are you going to use? Still better than ISE IMHO.
|
|
#
¿
May 30, 2013 19:04
|
|
|
Just going to post to bump again that if you want to move to beautiful Ann Arbor, MI and have FPGA experience (primarily) plus some hardware and Linux experience, there's a nice paycheck waiting.
|
|
#
¿
Jul 22, 2013 22:19
|
|
|
mnd posted:I remember you saying this was you trying to find someone to take over your old job, but aren't you in the PNW now? I'll be there in a bit, it's my last week right now, just trying to find them someone as I realize more and more how much they need someone fast. I am job'd up in the PNW though, certainly wouldn't move like 2500 miles without that lined up!
|
|
#
¿
Jul 23, 2013 21:27
|
|
|
Phone-posting, sorry, but IMO getting your job to pay for the better training courses, sponging off senior engineers, reading app notes and experimenting on your own are probably the only/best ways to improve your knowledge. Logic design is just one of those fields, I guess.
|
|
#
¿
Aug 5, 2013 04:17
|
|
|
Yeah, you're in solid shape I would say. Especially if you have a command of the English language and aren't one of the 1000s of Indian FPGA engineers who post desperately on forums cobbling together random example code into a product. Sounds like you're getting paid to learn and play with FPGAs, and you're doing pretty solid with it. I certainly wouldn't worry about Altera vs. Xilinx either; they're the two major FPGA vendor in terms of performance devices (Stratix and Virtex) though I think Xilinx still dominates in volume.
|
|
#
¿
Aug 15, 2013 16:52
|
|
|
A FPGA is a viable compute accelerator for a lot of applications, and here are the questions I usually ask: 1) Cost (is it even feasible to use a FPGA for this) 2) Development Time (writing HDL vs. implementing it in C/C++). Things like Simulink HDL Coder and others can (through loving wizardry) turn C code/models into HDL. 3) I/O - how do I get the data to the FPGA, i.e. PCIe? Ethernet? PCIe Hard IP is everywhere these days and will plug into essentially any modern computing system 4) Data Set size 5) How can I break down the problem into manageable chunks (i.e. pipelining) Assuming you have the knowledge needed for this task, the quickest way is to pick up a RDK that has a FPGA mounted on a PCIe add-in card, and then prototype. It will probably be much, much cheaper to try some GPGPU stuff for a quicker speed-up.
|
|
#
¿
Aug 29, 2013 21:19
|
|
|
Man I should just not waste my time with Vivado block design should I? I just want to route SD through EMIO and not use some of the pins from the default Xilinx SD interface, is that so much to ask?? I take it Vivado does not have a virtual pin facility or some other way to NC top-level nets?
|
|
#
¿
Sep 18, 2013 19:35
|
|
|
Anyone have any good PDFs/other links they'd be willing to share re: Verilog naming conventions? I have access to VHDL conventions from my previous job, but I'd be interested in seeing if anyone's publicly released their's. Not quite ready for "full" guidelines a la MISRA that define practices at higher levels, starting out small by just consistently naming poo poo. priznat posted:It is doable otherwise but I caved and went block design.. I had done some instantiating the zynq "primitive" but there's a lot more stuff to keep track of and being able to just dump right out to the SDK is a pretty huge advantage of Vivado + block designer. It's actually not too bad for connecting up AXI stuff but man, it is buggy as hell still. Delete a port sometimes, boom, vivado disappears. Ugh. So what I'm doing is the "non-project" Vivado flow described in UG892. I've kept a Vivado "IP Project" around simply for the ease of generating PS configurations and the resultant instantiation template, which I then place into my hand-coded top-level file. Once I get some more AXI IP, I think I'll manually be stitching up the AXI signals at the top-level to make sure they can talk to each other. The project flow has some weird restrictions and I have to get this project to play nice with the rest of our build system. I didn't think about your last paragraph though, that's another possibility I could explore and it seems doable from a Tcl POV; synthesize the PS7 stuff into a netlist and then consume at the top-level.
|
|
#
¿
Oct 23, 2013 01:50
|
|
|
priznat posted:Re: Zynq Ugggggh. 2013.3 came out today/yesterday, giving that a spin now.
|
|
#
¿
Oct 25, 2013 18:51
|
|
|
I do vastly prefer Altera as well, but Zynq currently runs circles around Cyclone V SX, IMHO. I think Altera lost a lot of design wins when Xilinx beat them to market.
|
|
#
¿
Oct 28, 2013 05:21
|
|
|
mnd posted:I think Xilinx is doing well with the Zynq and that class of part, but I think Altera is killing them in the high-end right now. Apples and oranges maybe? Yeah, I think it depends on what segment / market you are planning to target; in the SoC + FPGA space, I think Xilinx has it, but hopefully Altera can catch up soon / beat them with the next thing. Re: namechanges, PM me 
|
|
#
¿
Oct 29, 2013 05:06
|
|
|
Hyvok posted:Why are the Cyclone V S* so much worse than Zynq (availability is poor is only thing I can think of atm)? I've never looked at the Zynq because I used Xilinx ISE like once and it was so awful compared to Quartus that I decided I'll never want to use it again unless something dramatic happens. Honestly, it was mostly the availability and general shittiness of the development tools (I know, I know) at the time...we were promised repeatedly ES that we never got, there weren't cheap devboards like the ZedBoard readily available (when devboards are $300 a piece you can incredibly easily outfit your entire team), we got some kind of weird-rear end qemu-based VirtualTarget system for SW development vs github.com/xilinx, etc. This part is fuzzier and more FUD (I need to look at their datasheets again to be completely fair), but IIRC, the IOP muxing was really, really odd, compared to that on the Zynq. And on a higher-level, I believe the Cyclones have fewer, wider AXI ports to fabric than more, narrower AXI ports. All the above said, I think it'd be worth evaluating again now, just that for the past year, Zynq was the only option in town if you had a product in development and milestones to meet. e: last key difference I remembered is that fabric/processor are more divorced on the Cyclone; Zynq you always need to bring the PS up first. e2: Also the BFMs from Altera were mostly in SV, which meant we had to pay even more for another language for Incisive. movax fucked around with this message at 17:04 on Oct 29, 2013 |
|
#
¿
Oct 29, 2013 17:01
|
|
|
In Xilinx land, what's the best way for me to store some build information/other debug data on chip, ideally sourced from a .hex file? About 100 bytes worth (64 reserved for the hostname of build box). I recall utilizing a little IP in SOPC Builder/Qsys from Altera that could source an external .hex, which was nice because I can dynamically create that .hex with Tcl during the build flow. Performance obviously not an issue / huge driver.
|
|
#
¿
Nov 1, 2013 18:16
|
|
|
priznat posted:That would be cool. In the past we've used MAC ID proms (i2c) that also have some NV storage for host name etc, but building it into the fabric from the build script would be nifty. Yeah, if it wasn't for the hostnames, I'd just instantiate like half a dozen 32-bit regs to hold all the stuff and populate them with some verilog includes maybe. Having something that can suck in a .hex file would be cool. I like having it coupled right to the bitstream where it can't easily be messed with. Delta-Wye posted:I'm pretty sure this is something data2mem does. Thanks, I'll check this out. I noticed that the block memory generator only offers RAM with an AXI interface, ROM is only available with 'native', so I guess I'd have to write (or does Xilinx make a generic AXI4-Lite shim) a shim to get it to AXI/accessible from PS.
|
|
#
¿
Nov 1, 2013 18:59
|
|
|
Posted on the Xilinx forums about this as well, and I'm afraid of the answer, but for Zynq designs, can you export_hardware to SDK without being in a project/block-design flow? I hope so  Really want to avoid block diagram designer if I can (or anything that is primarily GUI driven because I need this to be 100% scriptable / adaptable to our internal build-system).
|
|
#
¿
Nov 12, 2013 18:46
|
|
|
I don't have access to the quote anymore, but QuestaSim was insanely well priced compared to our previous Cadence Incisive license. Didn't need any vendor-specific licensing, just picked the mix language support. Both Xilinx and Altera support it for generation of simulation libraries.
|
|
#
¿
Feb 6, 2014 10:28
|
|
|
Very slick design! Looks like a Cyclone V SX, are you using the ARM cores for anything?
|
|
#
¿
Aug 22, 2014 01:29
|
|
|
I'm writing some JTAG logic utilizing the UJTAG functionality of Microsemi devices (basically a way to implement your own custom JTAG instructions). I have a case where I want a particular DR to trigger a one-time pulse event. The UJTAG interface provides you signals that indicate CaptureDR, ShiftDR and UpdateDR. The last one is confusing me a bit: during UpdateDR, I latch the value from the DR into a 'shadow' register that holds the final value that was shifted in. I want this to be the trigger for the counter, which is fine. The counter runs off a completely different clock than the JTAG clock (of course). At the end, I want to the counter to disable itself, and the easiest way is to simply write a 0 back to the trigger register. However, that trigger register is clocked by the UpdateDR signal. So...I can synthesize if I feed the UpdateDR process a clock that is the OR of the UpdateDR signal + the internal clock, but I feel like that could be a little weird. With them OR'd, the register can be cleared, no problem, and if UpdateDR occurs asynchronously to the internal clock, that register can be updated. Still feel like I'm missing something though.
|
|
#
¿
Sep 25, 2014 03:01
|
|
|
Star War Sex Parrot posted:Female companionship.  Sadly true.minidracula posted:Why on earth are you using Microsemi anything? The IGLOO Nano is really low power, and has a rather SEU-resistant (supposedly immune) fabric thanks to being flash-based. I used it on a high-frequency DC/DC converter board with no real issues, and planning on using it a lot more going forward as a general utility device. I did end up working around my problem though and I've got a FPGA that can now help program / in-circuit debug MSP430s, which have the weirdest goddamned JTAG implementation I've ever seen (read: non-compliant). What I did was have a custom JTAG instruction that does nothing in the CaptureDR or UpdateDR phases, but during the ShiftDR phase, ties the TDI line directly to an output pin, meaning a shift of '101' at any frequency faster than 20kHz will give me my desired pulse-low. I might have to revisit it though if the current interface proves too slow and I need to move more logic into the FPGA; I guess I'll cross that when I get to it. Would be a similar process where I need a flag triggered by the JTAG clock to gate a process run by a different clock -- in the shower earlier, I was thinking I need to get a DFF with a CLR input to get a flag that is clocked and set in one domain, but reset from another. I've got some SDLC master IP to write in a bit as well -- spree of FPGA stuff before I dive back into hardware-hardware land. At least that will be for a FPGA with 6-LUTs... movax fucked around with this message at 07:13 on Sep 26, 2014 |
|
#
¿
Sep 26, 2014 07:10
|
|
|
priznat posted:A guy in the FPGA emulation group of my department just left and I briefly thought about moving there from my system design + test job but then I remembered how emulation is a loving nonstop pain in the rear end of wrestling with horrible vendor tools and getting poo poo from the higher ups because the asic group's unoptimized RTL won't run faster than 50MHz on an FPGA no matter what you do. That sounds like it could be terrifying -- the tools would be horrid. Cool concept though (academically pretty neat concept) but imagine working with all of those vendor tools of varying degrees of stability...bleh.
|
|
#
¿
Oct 2, 2014 17:07
|
|
|
|
| # ¿ May 24, 2024 20:09 |
|
|
That's pretty slick. I get the occasional marketing blast from Cadence advertising their Proteus platform (I think it's Cadence, might be Mentor). 6-8 Virtex 7000s IIRC for some absurd number of ASIC gates. Haven't gotten a chance to do any real ASIC work thus far, but I'm hoping to start biting into it next summer as part of masters', and perhaps corporately after that.
|
|
#
¿
Oct 3, 2014 06:43
|
|