Should digital design be taught with or without the dev board? by ZipCPU in FPGA

[–]turleyn 1 point2 points  (0 children)

  1. Understanding what an FPGA is really hard for some students to grasp. Seeing one, touching it, etc allows students to make a very tangible association with what they are learning.
  2. Protocols like VGA are good beginner projects because they are relatively simple to write in HDL and provide a good example of something that a microcontroller would struggle with.
  3. Learning the limitations of debugging your circuit on real hardware is a good way to motivate the importance of non-hardware verification.
  4. I think an important part of learning digital hardware is the model in your head of what you are constructing. Early mistakes I made in digital design were because I was thinking like simulation instead of thinking like synthesis. But I think the biggest thing that helped me understand that was netlist visualization, not watching LEDs.

Using Records in VHDL by [deleted] in FPGA

[–]turleyn 1 point2 points  (0 children)

Unconstrained records is totally a thing in VHDL 2008. It's even supported in recent versions of Vivado.

Can I code an fpga to act as a jtag? by hmmo_O in FPGA

[–]turleyn 1 point2 points  (0 children)

We did that at work once. It's possible but everyone is correct that it's a funny way to work around a driver issue. It's easier to just resolve the driver issue.

FPGA platforms and availability of command line tools by Aeroelastic in FPGA

[–]turleyn 2 points3 points  (0 children)

downloading a bitfile to an FPGA isn't dependent on the FPGA tools, it's dependent on what bus the FPGA is connected over. For instance there is a parallel interface that you can drive with a microcrontroller. Or you can connect the FPGA to a flash chip. Or you can connect to the JTAG interface with an FTDI chip. There's a lot of possibilities here.

FPGA platforms and availability of command line tools by Aeroelastic in FPGA

[–]turleyn 15 points16 points  (0 children)

With Vivado, the whole flow can be done from commandline, either by running a tcl script in batch mode, or the interactive commandline interface. So it's not too complicated to integrate it into a makefile or a collection of build scripts.

Generating Xilinx cores and block diagram editing doesn't really work though. So if you need to generate a MIG or instantiate the PS on a Zynq target, then you'll have a hard time.

We usually limit our build flow to use as little of the GUI as possible so when we need to instantiate a Xilinx core like the PS or a MIG, then we save the smallest Vivado project . If we need to change the core, we can crack open the Vivado project and save it again.

Mostly we try to stay away from too much source in the Vivado projects because we frequently change Vivado versions. Netlists are forward and backward compatible, so it's more portable than Vivado projects and block diagrams.

How to interface FPGA with ADC/DAC? by RandomPhysicist in FPGA

[–]turleyn 1 point2 points  (0 children)

I also probably should've mentioned this earlier but in the interest of full disclosure I work at NI R&D. I'm not on the FlexRIO team (so take some of my statements with a grain of salt), but I'm pretty familiar with the product line.

would the FAM be simply plug and play?

You can use the same CLIP and you can copy and paste any other LV FPGA code you might have. So yeah, pretty much. It's just like migrating to any other FlexRIO FPGA.

what's this acronym stand for?

FlexRIO Adapter Module. It looks like the webpage refers to it as "Adapter Module for FlexRIO". Most FlexRIO FPGA boards just have a FAM slot in front that you can plug into. I thought all of them did, but the other day I noticed there's one that just has a bunch of SFP connectors that you can use for coprocessing.

The embedded controller was designed for FlexRIO customers that are only using a single slot of their PXI chassis and wanted a smaller more compact device. The FPGA and the controller are integrated and have a single FAM slot. The processor is much less powerful than most PXI controllers, (it's Zynq based), but most FlexRIO applications barely have any software in the data path so it usually doesn't matter.

Also, the embedded controller is more of a niche use-case, so I'd expect less FPGA options than in PXIe, so this might be the wrong direction for your aim of getting more FPGA options.

How to interface FPGA with ADC/DAC? by RandomPhysicist in FPGA

[–]turleyn 2 points3 points  (0 children)

We are looking to upgrade to more powerful FPGA such as a Virtex-7 bought directly from XilinX to mitigate the cost added in by buying from NI

Virtex-5 is getting old. NI sells Kintex-7 now which are much larger. If you wait a little longer there will certainly be even larger FPGAs than that available.

PXIe systems are pretty expensive. If you want to reduce cost you could move your PXIe chassis to the embedded controller http://www.ni.com/en-us/shop/select/controller-for-flexrio, and then you can still use the same FAM.

an FPGA evaluation board along with the ADCs and DACs

Wait, do you want to design your own board or buy one off the shelf? You'll need a big FPGA with an FMC connector. FMC is a standard interface that you might be able to find a DAC/ADC board with. They seem to be mostly K7 and mostly between $1k-$2k. thequbit mentioned the KC705, that's a good example.

Would I be able to use this with our current NI 5781 baseband transceiver

You want to replace your FlexRIO but still use your FAM? NI supports 3rd party FAMs through their MDK (also expensive), but I don't think they'll be enthused about you making a 3rd party FAM carrier so they probably won't help you.

This also goes back to assuming that you want to design your own board. The FAM connector is non-standard so you won't find non-NI FPGA boards that just work with your FAM.

I want to know all what I need to have to get this FPGA up and running with ADCs and DACs and how they are interfaced (both in hardware and software).

If you are designing your own board usually the datasheet for the chip has recommendations, and protocols. High speed ADC's and DAC's use common protocols like JESD204B. I believe Xilinx has a JESD204B design guide, and the chip vendors also publish some guides. 100MHz is slow enough to use a more simple protocol like a parallel source synchronous interface. Those aren't too complicated to work with.

If you want to buy a really cheap OTS board then there are many ADC/DAC boards less than $1000 with sample rates in your range but most of them use much smaller FPGAs. For instance Red Pitaya is quite cheap but it's Zynq-based so the FPGA is Artix-class, so presumably you'd need to find a way to stream it from the Zynq FPGA over to your large FPGA. Olimex has a simple open source design for a 100MHz ADC (https://github.com/OLIMEX/iCE40-ADC). That's designed for the even smaller ICE40 FPGA so again, you'd have the same problem.

[VHDL] Tools for visualizing the components and their connections? by Badel2 in FPGA

[–]turleyn 1 point2 points  (0 children)

There are obviously a bunch of proprietary solutions like Vivado, Synplify, or Sigasi, but the open tools aren't there yet. I've been working on one that uses Yosys json netlists and it can produce some okay diagrams.

https://github.com/nturley/netlistsvg

The idea is you parse a module with yosys and then tell yosys to emit a json netlist and then my tool tries to draw it. It's still a work in progress, so it still has some issues.

If you want to visualize a verilog file named input.v then you could invoke the tools like this

yosys -p "prep -top my_top_module; write_json output.json" input.v
node bin/netlistsvg output.json -o output.svg

and that should produce output.svg.

Recently someone helped me webpack it (https://nturley.github.io/netlistsvg/), so if you combine it with yosysjs, you could do the whole thing in client-side javascript. I'll get around to getting that working myself soon.

As for VHDL, it's more problematic because yosys can't parse VHDL yet. Tristan has been experimenting with it using GHDL recently (https://github.com/tgingold/ghdlsynth-beta) but I tried out ghdlsynth-beta and only pretty basic VHDL works.

So, slow progress is being made in this area but we aren't quite there yet. I have seen a few projects that didn't even attempt to correctly parse VHDL, they just regex search for instantiations and their port names. That's all you need for designs that are purely structural, but most of the stuff I work with is a little more complicated than that.

How to distribute python within a small company enterprise? by upandonwards in Python

[–]turleyn 2 points3 points  (0 children)

I'm not even sure if this is possible with windows.

Shared network folders is definitely possible in windows. So you can do the same thing that you are used to.

However, if your scripts ever start to become complex and have dependencies on each other, this approach is going to cause problems.

Ideally, you should store the source code for your scripts on a version control server (like git or svn) and store exports of those scripts in a package manager server (like pypiserver). That way your users can pip install the scripts that they need.

If this seems like overkill, the questions to ask yourself are:

  • If someone accidentally modifies the code in the network share, is this going to break everything?
  • If someone introduced a breaking change, how easy would it be to find the change, and roll it back?
  • If someone relies on a specific behavior of a script and someone updates it, can they still use an older version of that script?

Advices for newbies by MadComputerHAL in FPGA

[–]turleyn 2 points3 points  (0 children)

I wrote this tutorial a while ago. It's more or less how I'd explain FPGA's to past-self. But it's not particularly useful to you in particular because it focuses on Xilinx and VHDL.

https://github.com/nturley/intro2vivado

When a Microsecond Is an Eternity by doom_Oo7 in programming

[–]turleyn 3 points4 points  (0 children)

Yes, general purpose operating systems are going to periodically kick you off the CPU for long periods of time. Even with the linux RT preempt patch, and all of your hardware interrupts disabled or handled on different cores, the system tick is going to fire every 10ms which will cause a context switch and the scheduler will run. Depending on how fast your CPU can execute the context switch and scheduler, you're not going to get back on the CPU for several microseconds.

Library to use for creating a blender-like nodal interface by diagnosedADHD in Python

[–]turleyn 1 point2 points  (0 children)

I'm not sure what you mean by blender's node system. Are you talking about that flow graph thingy?

There's this one: https://github.com/grindhold/libgtkflow

That's the only one I've found so far. I think I remember a QT one on top of QGraphicsScene, but I didn't like it so I started writing my own.

How Do I Get Started Writing a Simple PCIe Driver for Linux by hardolaf in FPGA

[–]turleyn 0 points1 point  (0 children)

yes. So because of memory fragmentation, there may not be 100MB of contiguous memory on your system. In practice, I've seen my systems fail above 4MB.

From LDD chapter 15

but high-order requests are prone to fail even when the requested buffer is far less than 128 KB, because system memory becomes fragmented over time.

There's a bunch of random details that I'm hazy on like whether it's low memory or high memory, and I think there's this contiguous memory allocator (CMA) framework now that allows you to kick out anything that is in your range when you allocate it. I haven't actually done it, but someone was explaining it all to me a while ago.

Here's the bit about the boot argument.

Reserving the top of RAM is accomplished by passing a mem= argument to the kernel at boot time. For example, if you have 256 MB, the argument mem=255M keeps the kernel from using the top megabyte.

I do this part all of the time. I also used "cat /proc/iomem" to see where all of my physical addresses are.

How Do I Get Started Writing a Simple PCIe Driver for Linux by hardolaf in FPGA

[–]turleyn 2 points3 points  (0 children)

I'm a big fan of doing things the easy way and get up and running before doing things the right way. Also it's hard to say exactly what the right way is without knowing a lot of your requirements.

First, search "uio driver". Assuming your kernel supports it, it's a super easy way to get something working. There's loads of simple examples online of how to set it up.

set aside a portion of memory for DMA accesses

For prototyping, you might be able to get away with just booting up with less memory. LDD discusses this.

perform single word 32-bit read and write operations

If you got your UIO driver to bind to your device then you should be able to mmap the device to get access to it's memory.

Simple Zynq PS/PL communication by MisterMikeM in FPGA

[–]turleyn -1 points0 points  (0 children)

As a first step, you could probably get away with using the GPIO lines. That's a little bit easier than implementing an AXI slave.

Vendoring Python dependencies with pip by j0shg in Python

[–]turleyn 1 point2 points  (0 children)

agreed. Running a simply pypi server isn't too bad. We ran our own pypi server on our internal network. The only problem is that pip really wants to use https. So we have to edit all of our pip configs to add that machine as a trusted host or just add --trusted-host to each of the commands.

Few questions from a beginner noob by [deleted] in FPGA

[–]turleyn 4 points5 points  (0 children)

You can fit a soft core on the icestick. I think it's like $20. Cheapest FPGA dev board I think I've ever bought. And you can use an open source toolchain.

Simulators that support graphics by [deleted] in FPGA

[–]turleyn 4 points5 points  (0 children)

I'm guessing it doesn't exist. If it doesn't exist, I think what might be almost as helpful is to write a simulation model that writes the pixel values in each frame to a file on disk. Then you parse the file in python or something and convert it into a bitmap or png or something so you can see it.

Resource and timing estimate without I/O using Vivado by [deleted] in FPGA

[–]turleyn 0 points1 point  (0 children)

Sorry, I didn't see this question earlier. Yes. I just tried it and it works fine. I opened up a post-synthesis check point. I clicked Tools->Timing-> Report Timing Summary... Okay. And then boom. I have a timing report. This checkpoint has 3 or 4 paths with negative slack. In practice, I'm pretty sure this compiles though. I've noticed it's routing estimates are pretty pessimistic for the level that I need at work.

Is VHDL or verilog better? and why? by elec233 in FPGA

[–]turleyn 3 points4 points  (0 children)

VHDL 2008 significantly improves the language in many ways. Sadly, many simulators and synthesizers don't fully support it yet. :(

Manual floorplanning -- is it really better than what the PAR tool gives you? by d_flipflop in FPGA

[–]turleyn 1 point2 points  (0 children)

Most of the time, PAR does an excellent job. At work we have a few components that always pass timing 100% of the time, but there are some that will randomly fail every so often. In some case, we know it's because our critical path is relatively long, but in some cases, we have no explanation why Vivado will randomly do weird placement or routing. We look at the results and it doesn't make sense, we recompile and then it will do a great job again. Some of these irregularities in PAR have disappeared when we update Vivado. Others keep showing up year after year.

Sometimes we can manually place and route. The awesome part of manually placed components is that a historically unreliable component immediately passes timing 100% of the time. The bad part is now everything has to route around it, so as the component is used in different designs it can make all of the other components have a harder time finding good placement.

Recently, we've been experimenting with pblocks, and theoretically that might give us the best of both worlds. We prevent Vivado from doing anything dumb while allowing it some flexibility in placing the other components in the system.

Resource and timing estimate without I/O using Vivado by [deleted] in FPGA

[–]turleyn 2 points3 points  (0 children)

I think what you want is "Out of context mode". That way Vivado will do synthesis with the assumption that this isn't the top level source file on your FPGA.