|
So can someone sensibly explain why I need to declare the output of a multiplexer or the like as a reg even though both I and the compiler know the resulting logic will not be registered? Obviously it's because you're using an always block. But if I use all blocking assignments and ensure that the output is defined in all 'execution paths' then there won't be a register created. It seems like it would make more sense to let me declare the output as a wire, and then have the compiler generate an error if I didn't meet the requirements of it being purely combinatorial. That way at least I know what's happening and if I messed up. As is it just silently gets turned into a real register, I guess?
|
#
?
Aug 18, 2013 16:10
|
|
|
|
| # ? Apr 25, 2024 21:54 |
|
|
I'll replace and/or edit this later with more concrete details (or a pointer another post in a more appropriate thread), but I'm looking to hire at least one person ASAP. Ideally with HDL experience, but flexible on that if highly self-motivated to learn. (If you have HDL experience but not in Verilog -- we're a Verilog shop, but we have staff (including me) who come from a VHDL background; as long as you're willing to work in Verilog, we're cool). Other wants include software development and maintenance experience, especially on Linux. Similar skills on Windows a plus; additional driver development and testing skills on Windows a big plus. We're still pretty flat as an organization, but the team you'd be working "in" most closely is focused on cryptography and other infosec-related engineering work/products. That said, there are a number of company-wide projects not exclusively focused on that which crosscut all of engineering, and you'd be expected to work on those, contributing where possible. We're in Seattle, so ideally you are already in Seattle, or are willing to re-locate on your own dime. PM me if interested in learning more. If you don't have PMs, let me know here in the thread and give me a way to contact you. minidracula fucked around with this message at 21:34 on Aug 21, 2013 |
|
#
?
Aug 21, 2013 21:31
|
|
|
Wow I forgot this existed! But pretty good timing for me to rediscover it. So I'm having a career conflict right now that maybe some of you career Verilog guys can answer. I graduated in December and have been working for an embedded systems company doing RTOS development (specifically VxWorks). I never really thought I would wind up in programming but it's enjoyable and for the most part interesting work writing drivers and porting over the OS to new hardware releases. I get to work with some cool cutting edge technology and I'm still close to the hardware writing in C and occasionally some assembly. But recently I have been having thought's about grad school and getting back to hardware design, I have a few friends who went out west to work for bigger companies doing Verilog design (Nvidia, fusion IO). They had much better gpa's than I did in school but I felt like Verilog was one of the things that I really enjoyed doing and I had a knack for. I'm wondering if I can get back into it at some point, I am worried about pigeon holing myself into a firmware developer position and in a year or two not being able to apply for Verilog design jobs because I've been out of practice and have no work experience. Has anyone transitioned to Verilog post college? Did you go to grad school to "refocus" towards hardware design? Popete fucked around with this message at 20:35 on Aug 25, 2013 |
|
#
?
Aug 25, 2013 20:31
|
|
|
mnd posted:I'll replace and/or edit this later with more concrete details (or a pointer another post in a more appropriate thread), but I'm looking to hire at least one person ASAP. Ideally with HDL experience, but flexible on that if highly self-motivated to learn. (If you have HDL experience but not in Verilog -- we're a Verilog shop, but we have staff (including me) who come from a VHDL background; as long as you're willing to work in Verilog, we're cool). Other wants include software development and maintenance experience, especially on Linux. Similar skills on Windows a plus; additional driver development and testing skills on Windows a big plus. Woah I didn't see this before posting my rant above! I would be interested in hearing some more about the position, can email me at pwojciechows at gmail dot com.
|
|
#
?
Aug 25, 2013 20:34
|
|
|
I'm wondering if an FPGA is a viable solution to a problem I'm thinking about. Let's say I have a well known algorithm, like a Hough Transform, that I want to speed up(or offload, or parallel. Is an FPGA the path to take? Is integrating it a monumental task? I assume you'd have to get the information in and out of the fpga quickly, and I'm not even sure how that would work...
|
|
#
?
Aug 29, 2013 19:42
|
|
|
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
|
|
|
Rescue Toaster posted:So can someone sensibly explain why I need to declare the output of a multiplexer or the like as a reg even though both I and the compiler know the resulting logic will not be registered? Obviously it's because you're using an always block. But if I use all blocking assignments and ensure that the output is defined in all 'execution paths' then there won't be a register created. The left hand side of any assignment in an always block must be a 'reg', which you already said. If it's a combinational always block, it will generate a wire. If it's a clocked always block, it will generate a register. That's it. Blocking/nonblocking/executionpaths discussion is irrelevant, except for creating latches. Latches are bad and we don't talk about them in FPGA Land. Switch to SystemVerilog if you can. There's a datatype called 'logic' that's usable in both always blocks and with assign statements, and can replace 'reg' and 'wire' for 99% of cases. There's also 'always_ff' and 'always_comb' blocks. The former ensures that you create nothing but registers (and errors will be generated if your flow creates latches). The latter is a nice syntactic replacement for 'always @*'
|
|
#
?
Aug 29, 2013 21:41
|
|
|
movax posted:A FPGA is a viable compute accelerator for a lot of applications, and here are the questions I usually ask: Looks like I need to explore gpgpu stuff first. Thanks!
|
|
#
?
Aug 29, 2013 22:34
|
|
|
Rescue Toaster posted:So can someone sensibly explain why I need to declare the output of a multiplexer or the like as a reg even though both I and the compiler know the resulting logic will not be registered? Obviously it's because you're using an always block. But if I use all blocking assignments and ensure that the output is defined in all 'execution paths' then there won't be a register created. This is one of the reason I like VHDL over verilog. Some of the eccentricities of C syntax made their way into verilog and it constantly throws me off. VHDL is, for me at least, easier to describe combinatorial logic especially since you don't have to use sensitivity lists. If your only using a 2-1 multiplexer or a series of 2-1 multiplexers you can use the code:
|
|
#
?
Aug 31, 2013 17:11
|
|
|
My biggest reason I prefer VHDL over verilog is that if has been a while since coding either (I go from RTL to board design to automation scripting to who knows what else) it is MUCH easier reading over VHDL to refamiliarize myself. Sort of like python vs perl. Also generates, configurations etc.
|
|
#
?
Aug 31, 2013 17:34
|
|
|
Verilog has had generate statements since Verilog-2001, and sensitivity lists are deprecated for anything other than maybe speeding up simulations.
|
|
#
?
Aug 31, 2013 18:55
|
|
|
Oh yeah that's right Vlog has generates now.. In any case I think you just prefer what you learn on and have a lot more experience on unless there is a huge advantage to switching over, and there really isn't (either way). They're both fine. Also it really shouldn't matter anyway, if you can write good synthesizable RTL the syntax of the language is the easy part 
|
|
#
?
Aug 31, 2013 19:04
|
|
|
Schmerm posted:Verilog has had generate statements since Verilog-2001, and sensitivity lists are deprecated for anything other than maybe speeding up simulations. When I say sensitivity lists I mean "always @(sensitivity list)". The fact that a 4-1 multiplexor or an encoder has to be described with it can make it hard to read from all the flip flops and state machines that need similar statements. I have preferred VHDL since combinatorial statements can be left out of these kinds of statements and the syntax tends to force a lot more structure. Some people tend to not like that second part which I think leads to them preferring verilog. Also as priznat mentioned, its very much about what language you learned on.
|
|
#
?
Aug 31, 2013 19:21
|
|
|
Today I learned about Altera HDL (AHDL). If you ever wondered what exactly a MegaWizard Plug-In does, and/or precisely how parameterized megafunctions and user-defined macrofunctions are implemented, look no further. Of course the only documentation is a 300 DPI scan and OCR of a manual only ever issued in hard copy, from 1995. Of course.
|
|
#
?
Sep 17, 2013 09:29
|
|
|
Ok verilog thread: what's a good book on high speed digital processing of stuff like Ethernet packets, or in general the design decisions that go into making high performance, essentially signal processing, designs? I'm asking this not because I'll ever get paid to design hardware, but because I'm going to be working on a data processing pipeline and the techniques that have started to come up in software seem old hat in hardware (lmax disrupter == ring buffers, lock free algorithms in general, etc) Stuff like Ivan Sutherland's micropipelines paper would be great, along with stuff like how you go about designing firewalls and stateful processing at line rate for 100gbps Ethernet (turns out you have basically mirror the hardware design, see netmap). I want to mine as much info as I can so I don't have to reinvent the wheel or use more Hadoop than I have to. Also there's 3 days left on the red pitaya zynq 7020 measurement device, which is a pretty great deal on kickstarter. I'm gonna see if I can make a non lovely oscilloscope UI for OS X. Thoughts? If I could afford a netfpga 10g I'd be all over that. The de0 nano gets you only so far but at least I got the or1k to run 
|
|
#
?
Sep 18, 2013 04:43
|
|
|
I'm sad to say this is the first I've heard of the Red Pitaya. I've apparently had my head in the sand all summer! EDIT: I read some more information about it and I'm still not sure if it's an amazing product or just an amazing advertisement campaign. Delta-Wye fucked around with this message at 17:42 on Sep 18, 2013 |
|
#
?
Sep 18, 2013 16:56
|
|
|
Delta-Wye posted:I'm sad to say this is the first I've heard of the Red Pitaya. I've apparently had my head in the sand all summer! A zedboard costs 400 so at the least you get a discount on that.
|
|
#
?
Sep 18, 2013 19:29
|
|
|
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
|
|
|
Malcolm XML posted:I'm gonna see if I can make a non lovely oscilloscope UI for OS X. Thoughts? I haven't looked at the internals, but the OLS client might give you a head start.
|
|
#
?
Sep 18, 2013 19:38
|
|
|
movax posted:Man I should just not waste my time with Vivado block design should I? 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. It's actually the FSBL that configures the MIO/EMIO outputs, so don't skip that part of the build, something I found out. My method is put any xilinx IP blocks in the block design, and for any of my own blocks I punch out AXI port(s) to connect them up. Wrapping the IP is a huge pain in the butt and definitely not worth it. The block design I synthesize then export the netlist to an .edn which I instantiate in a top level. The zynq block project I archive to a zip file to clear out all the xilinx generated garbage files. Works pretty good! priznat fucked around with this message at 07:37 on Sep 19, 2013 |
|
#
?
Sep 19, 2013 07:32
|
|
|
Glad to see we have a thread dedicated to this. I have 2 Verilog Projects for my ECE171 class, with the first being due in 3 weeks, yet we haven't even started yet. I snatched this book that was recommended by my professor. Any other resources besides the OP I can hit up? PDF for reference.
|
|
#
?
Oct 18, 2013 03:29
|
|
|
EconOutlines posted:Glad to see we have a thread dedicated to this. I have 2 Verilog Projects for my ECE171 class, with the first being due in 3 weeks, yet we haven't even started yet. I found this to be a decent verilog tutorial, though it isn't the best unless you already have good knowledge of HDL's in general. http://www.asic-world.com/verilog/veritut.html
|
|
#
?
Oct 18, 2013 14:43
|
|
|
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
|
|
|
Re: Zynq I found a really annoying bug, possibly with Vivado 2013.2, that if you use the GP1 port it doesn't seem to allow you to map to the correct address space if you convert it to axi4lite when you pop it out the top level of the created block. It keeps thinking it is at the GP0 space, ie 0x40000000 onwards. I'm moving to another company and I don't think they do much zynq stuff so that's kind of a bummer, but oh well.
|
|
#
?
Oct 23, 2013 04:09
|
|
|
priznat posted:Re: Zynq Ugggggh. 2013.3 came out today/yesterday, giving that a spin now.
|
|
#
?
Oct 25, 2013 18:51
|
|
|
Oh poo poo, I haven't switched to my halloween nick yet. Thanks for the reminder.
|
|
#
?
Oct 25, 2013 18:53
|
|
|
boovax posted:Ugggggh. I talked to the Xilinx rep in the area last Friday over coffee, he said 2013.3 fixes a LOT of problems. They were having some problems with VHDL synthesis even (and it turns out Verilog too - it barfs on things that DC and Synplify is fine with). He also said that this is the release where IP Integrator is actually ready for prime time.
|
|
#
?
Oct 25, 2013 19:23
|
|
|
Jesus guys, that sounds bad. Just go Altera already... synthesis works, and you get SystemVerilog support for all families, not just newer ones like with Xilinx. Here's my conventions I use in (System)Verilog:
|
|
#
?
Oct 27, 2013 23:07
|
|
|
It is pretty funny how much better the Altera tools have always been than Xilinx, it seems. I have only worked at one place that was an Altera shop and that was a short term contract. I was blown away at how much nicer the tools were to use, that's for sure. I'll probably just keep putting Xilinx devices in designs just because I'm familiar with them. Inertia is a powerful thing!
|
|
#
?
Oct 28, 2013 04:59
|
|
|
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
|
|
|
I think that is the case. Xilinx seems to hit device availability quicker and whoever is first, wins. I had thought Altera had a standalone product line to compete with Zynq, the Arria? Are they not out yet? Fake edit: ah not yet in quantity it looks like. Xilinx wins again! I am thinking of getting one of those lower cost Zynq boards from Avnet to play with. Gotta think of a fun project though..
|
|
#
?
Oct 28, 2013 06:12
|
|
|
boovax posted: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. Not that I don't expect the tables to turn yet again, but... (Contentless-)EDIT: How do us non-mods get in on the Halloween username action?
|
|
#
?
Oct 29, 2013 03:44
|
|
|
Last I had heard the Stratix(?) parts that could compete with the top Virtex 7s were a ways off. The 2000T is an absolute monster.
|
|
#
?
Oct 29, 2013 03:59
|
|
|
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
|
|
|
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.
|
|
#
?
Oct 29, 2013 10:49
|
|
|
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
|
|
|
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.
|
|
#
?
Nov 1, 2013 18:25
|
|
|
boovax posted: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. I'm pretty sure this is something data2mem does.
|
|
#
?
Nov 1, 2013 18:52
|
|
|
|
| # ? Apr 25, 2024 21:54 |
|
|
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
|
|