|
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 |
|
|
# ? May 5, 2024 19:29 |
|
taqueso posted:Does anyone have a suggestion for a test fixture library for Verilog? Coming from software it feels like there should be 20 competing open source projects, but I can't seem to find anything. Well it turns out that there is a library for this: The Open Verification Library with checkers for Verilog, VHDL, and SystemVerilog. I got FPGA Simulation: A Complete Step-by-Step Guide by Salemi, which, despite using Comic Sans for the cover, is a good book. The concepts in the book are based around the OVL. He presents a set of "levels" you can target, each with better verification than the last, from nothing to self-checking, automatically stimulated test benches. The idea is that each level is a small (relatively) amount of work to achieve from the one before, so it isn't an all or nothing jump to the perfect test bench.
|
# ? Oct 9, 2012 17:18 |
|
I want to time an event with my MachXO2 FPGA with a 24-bit timer. I can get to around 200MHz with a naive implementation, but it would be nice to squeeze a little more performance out of it. Using the "timer" module from IPexpress is slower than my implementation (around 170MHz IIRC). I've read some app-notes about making a fast timer by adding a prescaler. Basically, add a ring-counter in front of the ripple-counter. The ring counter can be super-fast, and the ripple counter has more time for the carries to propagate. That seems pretty straightforward on the surface, but I am having trouble connecting the two timers together - the part where the ring counter gates the clock to the ripple counter. Can this timer be coded so the tools will figure out the timing of the ripple counter automatically? Or do I need to specify custom timing constraints for the ripple counter? If so, how do I do that?
|
# ? Dec 17, 2012 23:23 |
|
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 |
|
Hey can I ask SystemVerilog questions in here? I've been doing verification for something like a decade so I can probably answer some questions about that kind of stuff, but for some reason I'm having a hard time doing an assertion that probably should be a covergroup instead. My implementation feels kludgy and awful and I'd be interested in any feedback. Basically I have a test designed to saturate a bus. An easy way to detect this is by consecutive active cycles of the valid signal. Following is a rough illustration of what I have going on. code:
I'm going to limp along with the fixed window for now, but it really rubs me the wrong way.
|
# ? Jan 15, 2013 19:15 |
|
Send the valid bit to a counter, reset on invalid, and throw a covergroup on that.
|
# ? Jan 15, 2013 20:35 |
|
JawnV6 posted:
I don't really want to use a covergroup because I would rather this specific test fail if the criteria isn't met, and I don't believe you can do that with a covergroup. Sure I could do: code:
|
# ? Jan 15, 2013 23:21 |
|
TehSaurus posted:But then the test can stop behaving correctly and I might not know until I run the coverage report at some later time. It would be much more convenient if it showed up a failure in my regression. Still, doing more reading I think this is supposed to work and I must just be doing something wrong. SVA semantics are supposed to be strict, meaning that unfinished sequences register as failures at the end of a test. Given this desired behavior I don't understand why SomeLargeNumber kludge wasn't acceptable Most of my work with SVA's is getting them to work outside simulations, as you can imagine it's a stricter set. Wish I could help more, but if that SVA landed on my desk I'd chuck it right back. fake edit: Why within 1[*1:$] instead of within 1[*0:$]? Why have the 'within' at all? Or even look for a rising edge if you just need 200 consecutive
|
# ? Jan 16, 2013 02:19 |
|
JawnV6 posted:Given this desired behavior I don't understand why SomeLargeNumber kludge wasn't acceptable Most of my work with SVA's is getting them to work outside simulations, as you can imagine it's a stricter set. Wish I could help more, but if that SVA landed on my desk I'd chuck it right back. Yeah, have I mentioned that I haven't used SVA for anything before ever? This is exactly the sort of stuff I was hoping to have pointed out. Within is completely unnecessary as using: code:
Again the reason I'm looking for a rising edge is that I do not want this assertion to fail if there is no activity on the bus, and I want the check to run exactly once if there is activity on the bus, regardless of the amount. I'm all ears if there is a better way to do that. Since valid may not be solid for the duration of the test, using: code:
I'm just going to use the one with the finite window. The SystemVerilog LRM references varying levels of strength for assertion semantics, the strongest of which says that the assertion must be satisfied prior to the end of simulation. I also have a Cadence guy saying: Cadence Guy posted:IUS uses "strong" semantics when evaluating SVA sequences. If the enabling condition He goes on to talk about an option to disable it via tcl, but I can't find it in our simulation environment (substantial onion effect going on here,) nor can I find an equivalent option for VCS. This bugs me for two reasons: 1.) It should work according to everything I can find. 2.) Now there's a possible test escape if the test winds up being too short for some reason. TL;DR: I am terrible at SVA and I hate it. Edit: Thanks for your input, I really appreciate it!
|
# ? Jan 16, 2013 21:12 |
|
TehSaurus posted:I'm just going to use the one with the finite window.
|
# ? Jan 23, 2013 00:41 |
|
JawnV6 posted:I don't have any more advice, but I keep thinking about the pathological case that makes valid look like a 20% duty cycle clock which passes your assertion without significant bus traffic. Are you talking about 800 cycles of idle followed by 200 cycles of valid, hence 20% duty cycle? That would be a corner case for sure, but it would still have 200 consecutive transfers which would create all the corner cases inside the dut. If you're talking about non-consecutive matches, 4 cycles of idle and one cycle of active, that would require the use of either the goto repetition operator (valid[->200]) or the non-consecutive match operator (valid[=200]). Please tell me that's what you're talking about and not something else. I really don't want to dig back into that poo poo tomorrow!
|
# ? Jan 23, 2013 06:06 |
|
TehSaurus posted:the non-consecutive match operator (valid[=200]) Woops, yup, that's where my head was. Sorry about that! My Atlys board just arrived. Digging into it tonight, 2x in 2x out on-board HDMI ports..
|
# ? Jan 30, 2013 19:25 |
|
JawnV6 posted:Woops, yup, that's where my head was. Sorry about that! I've always kind of wanted to play with an FPGA, even though my actual verilog skills are bad bordering on terrible. I have a friend who does of a lot of work with FPGAs and it sounds pretty awesome. Incidentally, I was talking to some folks from Cadence about converting some of our testbench components to UVM, and remembered my issues here. I asked them and they confirmed that my initial guess was correct, but that they knew we configured it the other way. So I did wind up at the best solution, given our environmental constraints and I can stop obsessing over it, yay! My latest toy is doing post silicon testing of relaxed load/store ordering on one of our parts. Doesn't really belong in the Verilog thread, but some academic types put together a really interesting suite of tests for this here: http://diy.inria.fr/doc/index.html They're dynamically generated based on your instruction architecture and it even has an automated front end (that is sort of broken apparently?) Anyway, I'll be sure to come back here if I run into anything interesting on my UVM adventures.
|
# ? Feb 1, 2013 16:53 |
|
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 |
|
TehSaurus posted:Incidentally, I was talking to some folks from Cadence about converting some of our testbench components to UVM, and remembered my issues here. I asked them and they confirmed that my initial guess was correct, but that they knew we configured it the other way. So I did wind up at the best solution, given our environmental constraints and I can stop obsessing over it, yay! TehSaurus posted:Anyway, I'll be sure to come back here if I run into anything interesting on my UVM adventures. movax posted:That's pretty slick looking, I've always wanted to play with HDMI some more. I really should branch out and do some more things at the firmware level, but the Atlys is keeping me busy right now. I've got it hooked up to a video source & TV and have some simple transformations working (invert colors, invert chunk of screen, etc.). Next up is getting the ethernet working so I can get some data back onto the host. I'll post in the Screenshots thread when I have something more complex working.
|
# ? Feb 7, 2013 19:13 |
I played around with the Atlys board and the HDMI connectors a bit and it was really frustrating. Their example code didn't seem to do EDID correctly, I had a design I was pretty sure should work but I went through 6 displays testing before I got one that would work. And it broke one LCDs DVI connector. Plus, shuffling 720p pixels raises some tough timing concerns I wasn't really ready to handle. I would be very interested in seeing your work when you get it done!
|
|
# ? Feb 7, 2013 20:06 |
|
I was aware of the EDID issue, but my TV does screwy reporting on that anyway so I've done modelines by hand. The source takes a little time to output, but eventually settles on displaying to a generic DVI TV, got lucky that I didn't have to muck with that. It's already reporting that I'm failing timing, but still generates a bitfile and works fine at 720p so I haven't bothered digging into that yet. I'm trying to make the pixel handling very thin, at the very most I'm going to take a portion of the screen and overlay it somewhere else.
|
# ? Feb 7, 2013 20:23 |
The original plan was to read in a hidef HDMI video from an arbitrary source, do edge detection, and output a modified HDMI video stream. I ran into a ton of trouble buffering 3 lines at a time to implement a Sobel mask, and ended up giving up on piping HDMI and instead displayed out of a hardcoded buffer due to issues just directly connecting the two HDMI connectors successfully. Lame, but it was a class project and this was a much better solution than nothing. Even then, I was only able to do a x axis Sobel mask. Honestly, one of the biggest issues holding me back on this project was the fact I was a broke-rear end grad student and literally didn't own a single device with HDMI because it was "too new" (last year ) Stock, lowres: Aggressive edge detection with the edges overlayed on the original image (was hoping to do this with live video and get a cartoony effect): Same edge detection, with non-edges marked as white: Hires image: Hires less-aggressive edge detection:
|
|
# ? Feb 7, 2013 20:58 |
|
That's really cool! I got really lucky with my video source, it's obviously trying a few different ways to get the video out before it finds the way that works. I had a similar college project. We had a camera module, the FPGA, and a separate Cypress board for USB. Had to write the async fifo to interact with the camera, the USB hardware to package it up, and the Windows MFC program acting as a USB driver to take the video. We tried to do edge detection, but one FPGA wasn't enough to fit the 'webcam' and the block XOR so we had a kludgy solution with two and the host shuffling data up and down USB to reach them. Needless to say your edges are much cleaner than anything I had
|
# ? Feb 7, 2013 22:45 |
Keep in mind I completely toasted a monitor's DVI port (luckily the the VGA port worked and I just rotated it back into the lab's collection, heh) playing around with the godawful HDMI example library provided for the Atlys board, so do be careful you don't toast something when you feed it bad input. This could have also been the Dell's fault, you'd think it would survive bad input to the HDMI connector but whatev. Anyways, you can do really neat stuff with FPGAs and I enjoy working in Verilog but looking at my report for that project I'm reminded how I get very frustrated with lovely documentation, terrible dev environments, and expensive development tools and I have yet to do an FPGA project where that isn't my main takeaway. Delta-Wye fucked around with this message at 23:15 on Feb 7, 2013 |
|
# ? Feb 7, 2013 23:13 |
|
JawnV6 posted:Awesome. Glad I didn't set you back too far I think UVM is quite similar to OVM. I used VMM a couple years back, and honestly the biggest differences are the sequencers and the TLM ports, both of which I think exist in OVM. It is nice that the methodology enforces a good boundary between black box and white box testing. I'm a strong believer that if signals inside the design need testing, that it should be done with white box assertions written by the designer. Granted, most of my experience is working on large designs, and it just doesn't seem like a good investment of resources for me to be exploring the design at that level.
|
# ? Feb 12, 2013 18:24 |
|
http://stackoverflow.com/questions/9028084/assign-ascii-character-to-wire-in-verilog I'm looking for a character array (because I'm lazy) and until coming across that I thought someone asking why they couldn't do recursion in verilog was the worst. It's like finding a staircase to a whole new layer of ignorance. He's expecting verilog to have some built-in functionality to convert ASCII values into their character representation. TehSaurus posted:It is nice that the methodology enforces a good boundary between black box and white box testing.
|
# ? Feb 14, 2013 21:46 |
JawnV6 posted:http://stackoverflow.com/questions/9028084/assign-ascii-character-to-wire-in-verilog 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.
|
|
# ? Feb 14, 2013 21:57 |
|
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 |
|
Delta-Wye posted:It took me a few weeks of trying different things to finally get the "describing hardware, not writing code" mindset. I was in the last class where they still taught digital design using a GUI instead of starting with Verilog. That kept me out of thinking of HDL's as C, although I understand why that stage would be dropped and students shuffled right into Verilog.
|
# ? Feb 19, 2013 19:52 |
JawnV6 posted:I was in the last class where they still taught digital design using a GUI instead of starting with Verilog. That kept me out of thinking of HDL's as C, although I understand why that stage would be dropped and students shuffled right into Verilog. There is that, plus undergrad students definitely follow the 80/20 rule.
|
|
# ? Feb 20, 2013 00:26 |
|
I doubt anyone in this thread wants or needs this, but in case I'm wrong, or in case someone knows someone who might... I'm selling a more-or-less untouched copy of Foundations of Digital Logic with Verilog Design, Second Edition over in SA-Mart.
|
# ? Feb 22, 2013 04:06 |
|
I don't have much time to comment on this right now, so I'll just drop this here as a placeholder for a future conversation: https://github.com/stacksmith/fpgasm Seems like he's generating XDL directly, which means he skips ISE's PnR phase (IIRC)... Related, see also: https://github.com/stacksmith/fpgasm/wiki/What-is-this and http://www.fpgarelated.com/showarticle/39.php
|
# ? Mar 27, 2013 22:40 |
|
Verilog might have its drawbacks, but it's an improvement over writing netlists. I'd think this was an attempt to get around Xilinx, but since it relies on an install that can't be it.
|
# ? Mar 27, 2013 23:26 |
|
mnd posted:I don't have much time to comment on this right now, so I'll just drop this here as a placeholder for a future conversation: https://github.com/stacksmith/fpgasm That...doesn't make any sense. In either VHDL or Verilog you can instantiate any primitive you want, and hook it up however you want. It's rare with slice/fabric elements though, because that tends to be one of those "if you have to ask, you're not qualified to use it" situations. And it becomes a migration nightmare when you want to move to a different device. It looks like a (rather poor) solution in search of a problem.
|
# ? Mar 30, 2013 06:43 |
|
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 |
|
Does anyone here have any experience with AutoESL (aka Vivado HLS in the most recent set of Xilinx tools)? I have a project to look into it and see if it's useful in practice. Earlier this week was the first I had heard of it. Looks like AutoESL was a technology and accompanying UCLA spin-off startup company that Xilinx acquihired in late 2010 or 2011? Seems like they renamed it and made it part of their Vivado refreshed toolchain effort.
|
# ? Apr 8, 2013 02:22 |
|
Figured this was a good place to ask... I've ordered some FPGA dev boards and toys and know it will take a long time to get up to speed, but is there any real maturity in the open source world yet? For example, I want to do some image recognition in c++, so I downloaded opencv and it let me get up to speed pretty quick. If I wanted to do something similar with an FPGA, am I wasting my time? Will I be writing my own TCP/IP stack when I want to send a packet?
|
# ? Apr 24, 2013 04:28 |
bobua posted:Figured this was a good place to ask... I don't know of many opensource toolchains that go end-to-end, but there are quite a few free (as in beer) tools to try, even from the big manufactures, that will let you go from code to synthesizing to programming the fpga in one terrible program. A lot of this seems to depend on manufacturer, but as far as I can tell, the hardware seems pretty tied to the vendor's toolchain. Do you have any hardware in mind? I'm thinking about buying some Xilinx gear and jumping in and figure I will becoming reacquainted with ISE Webpack shortly.
|
|
# ? Apr 24, 2013 07:02 |
|
Lattice has Mach XO2 prototyping boards for <$30 and it looks like the tool (Diamond) is a free download. Is this a decent place to start with FPGAs? Are there other "starter" setups I should look at? I'm not looking to do anything super-serious, just screw around educationally (though I wouldn't rule out DSP for audio).
|
# ? Apr 24, 2013 07:12 |
|
It's not open source but the Xilinx IP cores can be pretty useful for getting going on a lot of the basic elements in an FPGA like memory controllers, network, sdio, i2c etc. They're mostly all AXI based too so fairly straightforward to plug together to get going. If you can swing it I'd totally recommend looking into getting a zedboard (https://www.zedboard.org), has the new Xilinx Zynq device which combines a dual core arm processor with a logic fabric. It's nice because you can write or modify existing drivers and run a full up Linux on the board. However, it is $320 student, $395 regular Comes with a free ISE webpack, not sure if they are going to upgrade it to Vivado any time soon though. The full IP Integrator tools in Vivado are "early access license" only right now, which is annoying because in all the how-to zynq documentation the IPI is referenced all over the place. I thought I was going crazy hunting for the button when I found out from the FAE that I need that license. The Zynq is a great little device though, really liking it.
|
# ? Apr 24, 2013 07:15 |
priznat posted:It's not open source but the Xilinx IP cores can be pretty useful for getting going on a lot of the basic elements in an FPGA like memory controllers, network, sdio, i2c etc. They're mostly all AXI based too so fairly straightforward to plug together to get going. I've seen the zedboard and I was tempted to get one, but I don't know what the gently caress I would design with it that I could then turn into something that isn't a zedboard. I may use a microcontroller dev board, break out boards, etc, to prototype an idea but eventually I knock out a PCB and make a standalone solution. All of the Zynq chips are >$100 in small quantities (some over $200!) at digikey, the only supplier I've found that even carries them. Am I missing something obvious? Is there a source for small minimal gumstix-like breakout boards for the processor? EDIT: Also, only available in godawful BGA packages. 900-BBGA? gently caress that noise. Delta-Wye fucked around with this message at 02:19 on Apr 25, 2013 |
|
# ? Apr 25, 2013 02:05 |
|
|
# ? May 5, 2024 19:29 |
|
ARM+FPGA sounds like a hardware nerd's chocolate and peanut butter, but a lot of the ideas I have call for a more modest price point. Still, it's a neat gadget and I like the idea of having a processor and programmable logic together, it seems like a solution to a lot of frustrating IO problems. But an mbed and a more basic FPGA together would be < $100 so I might start there.
|
# ? Apr 25, 2013 02:12 |