/diy/ - Do It Yourself

>>1832994

>>1864983
Planning to buy one to create my own processor. I'm currently designing the ISA (instruction set architecture). Will have to learn Verilog before buying anything.

Anyone tried any of the QMTech boards off Ali? Tempted by the upper end Zynq board.

I am not touching them directly myself but my research group is

>>1864983

I use them to do DSP and some motion control stuff. Did an event driven RTOS on one a while back. I personally don't get why everyone is obsessed with MPU emulation with them.

>>1865825
What style of ISA are you doing?

>>1865892
>I personally don't get why everyone is obsessed with MPU emulation with them.
It's the only feasible option if you want to implement your own microprocessor (barring doing it with discrete logic), unless you have $15,000 to throw at a shared wafer run for a single chip.

>>1866002

>It's the only feasible option if you want to implement your own microprocessor

I get that, it just seems like the only thing I ever hear hobbyists/ home devs doing with FPGA platforms. I dunno, how many architectures can you dick around with until you want to do something else? I hit my limit pretty quick when I first got into it.

>>1865825
Wait so by 'create your own processor' you mean come up with the entire ISA? Why not just implement risc v or something?

>>1866507

Not that guy. Inventing your own isa is simpler than implementing risc-v. Risc-v instruction encoding is more complex than needed for a simple design so they could handle extensions. There are also more instructions than you need for a simple hello world. Really coming up with an isa is the simplest part. Plus implementing a normal processor may be boring. You can go off the reservation and implement a cray, or other sort of custom vector processor.

That said picking an off-the shelf isa lets you use off the shelf programming tools (which may or may not matter), and Risc-v is probably the best choice for that.

>>1866528
>That said picking an off-the shelf isa lets you use off the shelf programming tools (which may or may not matter)
The cool thing is that we have tools now which can automatically generate tooling for an ISA.
http://www.archc.org/

>>1866167
How many hobbyist projects would actually benefit from using an FPGA over a microcontroller?
Microcontrollers are so cheap and powerful now that you'd really have to be doing something advanced to be able to justify using a FPGA.

>>1866688
I have never seen a project that uses FPGA as part of a bigger system, while this is common for MCUs.

In school we had Xilinx Spartan3E development kits and did some custom 7-segment decoders and stuff. I liked the software generally and the schematic programming mode. I'd kind of like to do custom logic ICs to save money on TTL/CMOS chips. Probably not anything horribly complex but just different custom stuff in various projects I build. Honestly an FPGA may be overkill and a GAL/CPLD or something like that would be okay.

What I want is a THT chip for prototyping and whatever software interfaces with it should have a schematic programming mode. I really liked that feature. The chips should be easily available and the programmer should be relatively cheap. preferably. Really not looking to spend more than like $150, maybe $200 but it's a stretch. Yes I know there's a PIC chip with a programmable logic cell in it but that's not what I'm looking for. No schematic entry mode.

It was the Spartan-3E Basys 2 board from Digilent to be exact. I could get that board for about $100 actually but all the chips are SMD which is no good. Need to be able to program a chip, pull it out, and put it in my circuit immediately to test and prototype with. Don't wanna fiddle around with breakout boards and other nonsense. Gotta be DIP or maybe PLCC would be okay too.

>>1867533
>Gotta be DIP or maybe PLCC would be okay too.
FPGAs in those packages aren't really a thing. Not modern, middling-to-high performance anyway.
Also most fpgas are programmed at bootup from external storage, many don't have on-board flash.

>>1867590
I was really leaning more towards CPLD or GAL moreso than FPGA although I would've accepted a FPGA if it fit my weird requirements.

>>1867590
I think digilent has some cplds and maybe a small FPGA in a dip form factor. Its a PCB with pins. That sounds like what you are looking for.

>>1867604
Kind of but not really. Ultimately I want to be able to program chips then remove them from the programmer and integrate them into an actual circuit. I don't want to pay $60+ for a dev board and put one of those into my circuit every time. It's expensive and takes up too much space. I want a bag of cheap ICs and a programmer (w/ schematic programming mode) and I just program a chip and whack it into a breadboard or a PCB if I'm done prototyping.

I'm not doing anything ridiculously complex. No CPU stuff. Just some custom logic for various applications to eliminate the need for discrete logic.

>>1867521
What? FPGAs are almost always just a part of a larger system.
It's not really economically viable to shove an entire system into an FPGA unless the task is fairly simple, or you're prototyping for a run of ASICs.

>>1867605
This may be the stage of your current level of comfort with electronics, however, easing into smd, smaller bgas, and hdl driven logic design is a pretty small step from where you seem to be, admittedly though you probablyl need at least a microscope and hot air tool for smt. Making a larger next step in terms of hardware than you are thinking about might be lower effort, cheaper, and give you greater capabilities faster in a long term view. But don't read that as shitting on your dreams or plans; different strokes for different folks, and all that.

>>1866688
Anything doing DSP. Also if you're going to be making a simple processor just go for the MIPS architecture. It's dead simple but has good tooling.

i have a big tv with dead main board, tcon and panel work fine. tcon accepts two 4lane lvds inputs, one for picture one for osd. talk me out of using an fpga to do either hdmi -> lvds or 2*hdmi -> lvds. haven't looked into it properly yet but i'm assuming this kind of thing is much better suited for fpga than micro? no idea what kind of clock i would need like i said haven't started yet. all the boards you buy seem to be set up for specific panels and i don't have any info for the tcon so id rather have something interesting i can fiddle with than buying something wrong. any advice appreciated. i have an fpga dev board somewhere no idea what core, similar to de0 i think.

>The Zynq family is based on the Xilinx AP SoC architecture, which tightly integrates a dual-core ARM Cortex-A9 processor with Xilinx 7-series Field Programmable Gate Array (FPGA) logic.
What are these hybrid boards for?

>>1869424
You get easy access to a CPU without implementing one in logic or having to go through the pain of using PCIe. They expose a set of AXI interfaces so the FPGA can access the system's memory and the CPU can access the cores implemented in the FPGA using memory-mapped IO. You can run Linux on it, Xilinx provides drivers in their fork of the kernel, in fact, a lot of them have already been merged into mainline Linux.

>>1869424
Cpus are really useful things to have around, and a hardened cpu dosen't take up much silicon area. It makes sense in a lot of cases to toss a couple hardened cpu cores as a generic thing onto a fpga and pull the main soft cpu out of the fabric; you might end up needing a smaller device as a result, and the hardened cpu will run at higher clock rates.

Things with high algorithmic complexity, like networking stacks run on cpus. For example if you wanted a network attached oscilloscope, you would push the buffered ADC interfaces and timing generation into the fpga fabric because that is perfect for it, but your top level web and gigabit network interface would run on the cpu in normal compiled code. In this case you would probably partition the ram, so the daq samples and the OS's memory are stored in the same memory chip. Having a single silicon device that can do all of this drops your product size and cost.

>>1866507
Not him but ISA work has stagnated. We are stuck with x86 (with derivatives) and ARM, while RISC-V is merely warmed over MIPS. Trying something new should be encouraged.

>>1870055
>RISC-V is merely warmed over MIPS
I'll take that over ARM any day.
Among other reasons, MIPS died because it wasn't very extensible.
As you said, RISC-V basically is basically a revamped MIPS with a best-of compilation of features from other RISC architectures.
They left plenty of space for extensibility in RISC-V so it should be good for the years to come.

At any rate though, if you're making a CPU on a FPGA It's more fun to create your own ISA.
You get to learn why certain design decisions are made, and you also get to play with some more off-the-beaten-path style designs if you so desire.

>>1870055
>Not him but ISA work has stagnated.
To be honest, if we learned anything from the whole RISC/CISC wars, it was that the ISA isn't really the end-all-be-all.
The magic is all in the microarchitecture, especially when out-of-order comes into the picture, where the underlying implementation may not even resemble the actual ISA.

>>1870377
>Among other reasons, MIPS died because it wasn't very extensible.
How come?

>>1870450
>The magic is all in the microarchitecture
Also cache technologies. Caching is second guessing the program flow. Very few architectures hint at what will happen in terms of cache fill and flush.

>>1871171
>How come?
MIPS has a fixed instruction size, so you had to work within the existing instruction formats.
To start, MIPS only allows for 4 co-processors, of which 3 are already taken (CP0 is the system control processor, CP1 is the floating point unit, and CP3's instructions were cannibalized to implement 64-bit support in MIPS III).
Next, there's only encoding space for up to 256 instructions per co-processor, but far fewer will be available if you wish to support instructions with immediate values on the co-processor.
Only being able to write to a single register caused also headaches for implementing multiplication and division, since they return values to two registers. This lead to the HI/LO accumulator registers being added as a workaround, which is a bit of a wart.
The fixed 5-bits for shift amount in R-type instructions also caused problems when moving from 32-bit to 64-bit because 5-bits isn't enough to specify shifts longer than 32-bits. That meant that 64-bit shifts were implemented with two instructions, one for 1-32 bit shifts, and a second for 33-64 bit shifts.
The limit on there only being two source registers also hampers SIMD extensions somewhat, since it means you can't do things like have two source registers and a mask register.

RISC-V on the other hand is a lot more flexible when it comes to extensions.
First off, MIPS already went through the growing pains, so RISC-V can jump past those issues and go straight to the better solutions.
Next, RISC-V only nominally has a fixed 32-bit instruction length. They left encoding space to allow for 48-bit, 64-bit, and 128-bit long instructions, as well as compressed 16-bit or 24-bit instructions.
That leaves a huge amount of space to add new instructions and formats.

>>1864983
>Anyone here working on anything to do with FPGAs?
Early days still but I am looking into making a FPGA goniometer for ham radio. Problem definition takes a bit of time, not sure what size FPGA I will need.

The idea is to have 4, 8 or more dipoles in a circle, each connected to an ADC, feeding into the goniometer. Each channel is processed with FFT and then combined and analysed with MUSIC to determine a direction, which has a lot of weaknesses. Also the channels are combined in a manifold rotated around 360 degrees to see what fits are best, producing a radar like display of a frequency band of interest, say the 40 meter band. That way you can focus on the signal you want and exclude noise.

A more sophisticated solution would also take elevation into account.

bump

>>1871288
So how can we improve cache handling and hinting? I am thinking about bringing back the zero page since the usage patterns of it and the stack are really very different.

>>1873830
>So how can we improve cache handling and hinting?
Good question, especially since cache is usually designed to be transparent to the program running.
The biggest problem would probably be making sure that the hinting system doesn't limit future improvements.
Once you move a feature out of the microarchitecture and into the ISA, you're pretty much stuck with it forever.
For example: both MIPS and x86 (Pentium 4/Netburst) had branch prediction hint instructions, and both removed them since it tied the branch predictor to it's (then) current behavior, limiting options to transparently improve it in the microarchitecture.
MIPS also put effort into removing the branch delay slot and the load delay slot since it ties the ISA's behavior to the original 5-stage in-order pipeline.

>I am thinking about bringing back the zero page since the usage patterns of it and the stack are really very different.
An interesting idea. Not sure how well it would work in today's multithreaded, multiprocessor, out-of-order world.
Since every process runs in it's own virtual address space, the zero page for a process could be anywhere in the actual physical memory.

>>1873830
>bringing back the zero page
Closest thing I can think of in modern hardware is scratchpad memory.
You usually only see it in processors which are dedicated to a single task, since the overhead of having to spill and fill the scratchpad to memory during a context switch would negate any benefits.

>>1874278
The zero page got a lot of bad press, perhaps that is why it was renamed into scratchpad memory.
Spill and fill is a problem, I agree, then again you have the same issues with cache flushing. My very early thoughts about this is to have a zero page for each task and persuade the programmers to exploit it maximally since it is far faster and makes programmes denser.
Zeropage is intensely used, stack frames in these systems are less used and the usage pattern is different. Same with heap, allocations there are more transient so you can experiment with different settings for caching the different areas.

>>1874398
>then again you have the same issues with cache flushing.
I don't think the issue is quite as severe with caches, since the cache only has to flush cache lines which were written to and everything else can just be discarded.
When the context is restored, the process can start immediately since the cache doesn't have to reload any lines until they're accessed again, a preload instruction is encountered, or the cache controller predicts a line needs to be preloaded.

Compare that to scratchpad memory where the whole scratchpad needs to be saved and restored every time a context switch happens.
The scratchpad could be split into smaller pages, but at that point it starts to become less of a zero page and more of a manually managed cache.

The Xeon Phi has an interesting approach though. It has 16GB of on-board RAM which can be configured as scratchpad memory, cache, or both with the split being controlled by the program running.

>>1874561
I am just following along with your dialog here, but aren't context switches going to be more expensive in general because of all of these speculative attacks? If you need to flush your caches anyway, maybe a scratchpad isn't so expensive.

>>1874660
>aren't context switches going to be more expensive in general because of all of these speculative attacks?
True, spectre really throws a spanner in the works.

>If you need to flush your caches anyway, maybe a scratchpad isn't so expensive.
As I said, cache only needs to write back to memory whatever cache lines are modified, meanwhile the entire zero page would have to be written back.
On context restore, the entire zero page would have to be read back from memory before the process can start, while with a cache the process can start immediately and the cache controller can preload data while the process is running.

Scratchpad memory makes sense if you don't swap contexts very often, but I'm not sure if it would work so well on personal computers or cellphones, where context swaps happen hundreds of times per second.

>>1874705

It's my understanding that this:
https://lore.kernel.org/lkml/20200313220415.856-1-sblbir@amazon.com/

invalidated the cache lines. Linus shitcanned it iirc - because it was so expensive, but was willing to be convinced it was important.

>>1865838
Yeah I grabbed the Artix-7 100T board.
I haven't done much with it as I'm trying to get it going with the open source toolchain but everything seems to be in working order.

>>1874919

I don't know how they are doing this. A xc7a100T chip alone is more than $109 considering both digikey and avnet. The aliexpress price is $95.90.

>>1874731
Sorry, I'm not following your point here.

>>1875108

I think that invalidates all the l1 cache on task switch, which means that it isn't all that different from a zero page in that the cache controller is going to have an immediate cache miss on any switch into a different process.

I have implemented dirty bits for cache lines, I do understand how that works.

>>1875307
Yeah, you'll get a few cache misses when the thread starts, but preload instructions and data access predictions can ease the overhead, and not every instruction accesses data.
Compare that to a zero page where you're forced to load the ENTIRE page before the process can start.

any forth programmers here? what advice would you give to your young self.

>>1864983
Yeah, I was working on some custom boards with ECP5 12K luts chips on them. Can pick those up on digikey for cheap (5-7 dollars from what I remember).

Created custom kicad schematics. Had a play around in lattice diamond with a development board.

Then I found out about Symbiflow, spent ages building it and getting it to work; grew bored and abandoned the project.

Maybe I'll come back to it at some point. Anyone else messing around with ECP5s?

>>1874972
Yeah I have no idea, especially considering I got it for 80 CAD. I'm just happy I got a decently featured board for me to mess around with recreationally that wasn't 200+ USD like the digilent or numato ones I looked at.

Anyone here ever tried to make a CPU cache?
I feel like I could probably get a 2-way associative cache working, but once DMA and multiprocessing enter the picture issues like cache coherency become such a headache.

>>1875998
I have done it. Not terribly difficult.

A related question: in a 4 way or higher cache, how do you implement picking the least recently used cache way to discard and fill? With 2 way it's trivial. I have done something that works for a 4way, but it involved a random choice iirc.

>>1876204
The easiest method I know of is Pseudo-LRU.
https://en.wikipedia.org/wiki/Pseudo-LRU
It's not always perfect, but it is very simple and good enough.

>I have done something that works for a 4way, but it involved a random choice iirc.
Can't be that bad, ARM Cortex-R processors, for example, just chose an entry at random for replacement, no fucks given to usage patterns.

>>1864983
I did my final research project thing at uni with FPGAs/VHDL, and was meant to be starting a job working with them in April, but Corona has fucked that till atleast September.

>>1876204
How did you deal with cache coherency issues?

>>1875335
>any forth programmers here? what advice would you give to your young self.
I don't do Forth but I would recommend joining a forum with a special interest in this. Many are related to specific microprocessors, such as the Forth section of forum.6502.org.

>>1877307

Single processor. It was riscv so there are specialized instructions to flush and invalidate caches. FENCE and FENCE.I . My bootloader is network aware and can write programs into memory then jump into downloaded code, so I had to implement both instructions.

>>1878164
No DMA support then?

>>1878216
I have DMA in the nic MAC. There has been at least a year since I did this, so I might have a detail wrong. The memory controller is multi ported and the nic has a port. After writing a block of data to ram and DMA instructions, fence is called which flushes dirty pages in the cpu cache into main memory. The CPU writes to an address which is a command register for the nic which is in a noncached region. The nic state machine spins up and moves blocks of data into its local brams and does the tx. I am a little hazy on RX without looking at the code, but I think my fence also invalidates the data cache, so you flush the data cache, spin up the nic DMA engine over the command bus which writes data to the sdram chip, then you wait for the dma to complete, then you can read data normally and the cache pulls in blocks as needed.

>>1864983
Ive never really understood the purpose of fpgas. Is it just when you need hardware silicon speed like fast io stuff? MCUs like the teensy 4.0 hit 600mhz and with overclocking/cooling 1ghz so I cant really imagine much else. Maybe multiple hardware loops running.

>>1878284
FPGAs are for when you want an ASIC but the production volume is low enough that it doesn't make sense to pay for an ASIC production run.
>Is it just when you need hardware silicon speed like fast io stuff?
Yeah, pretty much. If you need lots of fast IO, it's hard to beat dedicated hardware.
>Maybe multiple hardware loops running.
Also yes. If you need multiple real-time tasks to be carried out concurrently, it's a lot easier to do that in hardware than software.

You'll also sometimes see FPGAs used to implement hardware accelerators for specific tasks, like matrix operations or DSP stuff that runs pretty slow in software.

>>1864983
Is this a regular general here? I'm just getting into IC designing.

haven't done any HDL in a while lads :(

>>1879605
It moves pretty slow, but its a regularly occurring thread.

>>1879605

Directly in silicon, or in fpgas? Either way, describe tool chain for thread enjoyment!

Anyone try this shit?

https://github.com/fupy/fupy.github.io

Seems kind of dead. Wonder if it's because Migen got deprecated by nMigen.

>>1871171
>>1870450
Both good points.
See also: https://queue.acm.org/detail.cfm?id=3212479

>>1880625
That was possibly the stupidest and most biased opinion piece I have ever read.

Are there any good tutorials for getting into FPGAs, something like the Gooligum tutorials for PIC?
Also would the ARTY S7-50 be a good board to begin with?

>>1881071
>ARTY S7-50
Yeah, that looks good as long as you don't mind working with PMOD and Arduino style pin headers.

I always though that fpga4fun.com was a decent intro if you already understand digital logic and a little VHDL.
It's not super in depth, but it gives a good starting point to build off of for simple projects.

>>1867601
Tinyfpga or something else in the Lattice family. The open source tools make programming a breeze.

I'm an FPGA engineer. All I do all day is work on things that use an FPGA.

These are some ADC values that I'm storing in a FIFO. I know that the noise (the little jumps/deviations from the straight line) shown here is not actually from the ADC, so I'm thinking it has something to do with the synchronization as it's being read into the FIFO. Does that seem likely given this data? I thought bit synchronization problems would only mess with the bits that are being changed from one clock cycle to the next, but this seems to be flipping other bits.

>>1884240
Guess that was it because I put some phase offset on the write clock of the FIFO and the noise disappeared. It looks so pretty now. There's some really bad overshoot on this old supply I'm using though.

>>1865825
have fun with it. great way to learn. you got a spec somewhere public yet or nah?

Does anyone have some good books on VHDL?
We had labs with FPGAs this year so I know the basics but I would like to expand a bit

>>1869424
It's literally in the name SoC (System on a Chip). I use these at work and they are wonderful to work with. It's a breeze integrating an OS, RTOS or Linux with the FPGA fabric. Write your HDL for the FPGA, and control it using the ARM core. Great stuff, only downside is the price.

>>1884697
>books
Free download
https://link.springer.com/book/10.1007/978-3-319-34195-8

>>1864983
Playing with an icestick.
Fucker sure leeches power.
The tinyfpga I'm also playing with only draws 5mA for the same "blink the led".
IceStorm ftw

>>1884697
Not strictly books, but:
https://www.nandland.com/articles/fpga-101-fpgas-for-beginners.html
https://lawrie.github.io/blackicemxbook/
https://github.com/Obijuan/open-fpga-verilog-tutorial
https://www.fpga4fun.com/
http://www.fpga.synth.net/
Much reading to do. HF, Anon.

>>1886661
Nice.
Perhaps we could put these in a paste for next OP?

I always though this was a rather neat project, even if it isn't practical in the slightest.
http://blog.notdot.net/2012/10/Build-your-own-FPGA

Anyone here ever tried to make a 3D graphics accelerator?
I'm thinking about doing something capable of hardware geometry transform and gouraud shading. Maybe some hardware lighting, but probably no hardware texture mapping.

>>1889292
I have seen a web page where someone built a GPU from scratch. I have tried but cannot find that site again but I do remember he got it to work.

first time Sauder iron few minutes ago. sauder iron, plug in. that part of board instantly burns off. kek

Verilog / yosys stupid Q:

I have some counter that gets compared with this TICKS parameter
parameter TICKS = 400;

It works, but it's inconvenient. I want to save myself the pain of calculating TICKS, so I try using an expression.

parameter FREQ = 17000;
parameter TICKS = 0.5*(12000000/FREQ);

Calculated doesn't work because TICKS somehow turns signed, and later some comparison fails some yosys validation because of that. I can just force both sides signed and it works:

parameter signed TICKS = 0.5*(12000000/FREQ);
reg signed [31:0] r_COUNTER = 0;

But that's not what I want. I want to get rid of signed. Unfortunately, putting "unsigned" in both ends doesn't work, because unsigned doesn't seem to be a reserved word. I try to force it by casting it via $unsigned() function:

parameter TICKS = $unsigned(0.5*(12000000/FREQ));

But then I get "ERROR: Failed to detect width for parameter \TICKS!", therefore something must be very wrong, but for completeness I try forcing the parameter size:

parameter [31:0] TICKS = $unsigned(0.5*(12000000/FREQ));

And it fails with the same error. Advice?

>>1889685
After further fighting, found solution, so I reply to myself.
These do all work:
parameter TICKS = $unsigned((12000000/FREQ)/2);
parameter TICKS = $rtoi(0.5*(12000000/FREQ))
parameter TICKS = (12000000/FREQ)/2;
Therefore, ultimately to do with the warning:
Warning: converting real value 4.486500e+03 to binary 4487.
Getting rid of the real value, or making the conversion real->integer explicit, got rid of signedness in parameter.

>>1889685
show the rest of the code, i doubt the parameters is your issue.

When in doubt, leave everything unsigned, and only use 'reg' or 'logic'
types.

>>1889711
Code does now work as per >>1889706
All it does is generate a clock signal at the given OFREQ, at 50% duty cycle.
Whole code below. This is my first attempt at writing some verilog from scratch outside of following tutorials, so I do expect it to be crap.

module freqgen (i_clock, o_clock);
input i_clock;
output o_clock;
parameter CFREQ = 12000000;
parameter OFREQ = 1337;
parameter TICKS = (CFREQ/OFREQ)/2;
reg [31:0] r_COUNTER = 0;
reg r_OUTPUT_EDGE = 1'b0;
begin
always @ (posedge i_clock)
begin
if (r_COUNTER == TICKS-1)
begin
r_OUTPUT_EDGE <= !r_OUTPUT_EDGE;
r_COUNTER <= 0;
end
else
r_COUNTER <= r_COUNTER+1;
end
assign o_clock = r_OUTPUT_EDGE;
end
endmodule

For instance, yosys builds it fine (and it works on the fpga hardware), but iverilog craps out:

$ iverilog freqgen.v
freqgen.v:9: syntax error
freqgen.v:14: error: invalid module item.
freqgen.v:15: syntax error
freqgen.v:15: error: Invalid module instantiation
freqgen.v:18: error: invalid module item.
freqgen.v:19: syntax error
freqgen.v:20: error: invalid module item.
freqgen.v:21: syntax error
I give up.

>>1889714
can you set your iverilog compile options to use verilog 2001 syntax maybe.
The later standards are a lot more lenient and all round nicer to work with.

who else here /overworked/ and nearing deadlines?

>>1889726
Yeah, that was the first idea. I tried all the version targets. They all give the same error output, not even a difference. There's likely something fundamental I am missing there.
Unfortunately the free toolchain ecosystem is in early stages and somewhat unapproachable, but I am trying to avoid getting into vendor-specific tools, getting used to them and then getting tied to a proprietary ecosystem.

>>1889730
can you post full code + line numbers?

its usually 1 small thing at top which invalidates syntax of everything afterwards

>>1889732
Image, straight from vim, as I'm not sure how to format better on 4chan.
Note I'm aware I'm supposed to build a test bench, but that's a separate issue. Test bench does include the actual freqgen.v file in the first line, which throws the same errors.

>>1889714
>>1889732
>>1889735
Nevermind, found the fucker.
The outermost begin/end is superfluous. It isn't in an "always" or the like. Apparently it cannot be naked.
Now iverilog is happy. and yosys still is.

Any recommendations for an FPGA + ARM SoC devboard with display output and which has good enough floating point performance for some DSP stuff? I want to dick around with some stuff that probably requires decent floating point performance. Budget is $500

Also, what are some features you would want from an HDL that would make bringing up designs easier? For example, I think being able to specify the underlying value of enums would be particularly useful in some instances. Another example would be entity instantiation that doesn’t require connecting all ports in the instantiation so you could refer to an entity instance’s signals by entity name without having to create a record/signal, connecting that, then referring to the signal.

>>1889622
probably this https://libre-soc.org/3d_gpu/

>>1890996
That looks neat, I'll have to check that out.
I've been looking at this one:
https://github.com/HeavyPixels/QuickSilverNEO
https://hackaday.io/project/11815-quicksilver-neo-open-source-gpu

Anyone drive themselves crazy trying to figure out what compromises to make when designing a CPU?
I'm trying to make an ISA that's as easy to use as the Zachtronics (TIS-100, Shezhen I/O) ones, but with out being overly restrictive.
As a part of that, I'm trying to keep the instructions fairly regular so you don't wind up with some functionalities limited to only some of the instructions.

For instance: I recently changed my branch instructions from comparing a single register against zero to being able to compare two registers against each other.
Now to keep things regular I would like for my 'conditional select/move' instruction to be able to directly compare two registers as well.
But doing that means that the 'conditional select/move' instruction accesses as many as 5 registers (4 read, 1 write), which is fucking ass from a performance standpoint due to the absurd number of read ports needed for a single instruction and increased chance for a data dependency.
Not to mention I only allow for a single immediate value per instruction, and I'm not sure which register the immediate would be most useful for.
Normally I'd look at usage patterns and make a compromise based on that, but I don't have much data for this kind of thing since it's kind of an oddball instruction.

>>1891027
Does your cmov instruction do the comparison too? Any reason to not just have a compare instruction that sets flags and different cmov instructions/params for eq, neq, etc? Also why do you need four read ports, wouldn’t you just break it into multiple cycles anyway, requiring at most two simultaneous reads?

>>1890640
One of the xilimx Zynq SoCs.
There are cheap ones with hdmi out iirc. PYNQ-z2 i think is only 100£

I think both VHDL and Verilog support both those features you mentioned - definitely verilog/sysverilog anyways. Can specify all enum values, and ports are autoconnected with *, to a signal with the same name.

>>1891027
>>1891302
this, desu

conditional instructions should compare against internal processor flags, same goes for branching etc.

For ease of programmimg you can have macros so that compare and move instruction is broke into 2 instructions, compare, and conditional move.

You'd get better overall performance, and an easier design that way.

>>1891302
>Does your cmov instruction do the comparison too?
No, but now that my branches do I'd kinda like for CMOV to do so as well.
>Any reason to not just have a compare instruction that sets flags
I do have that instruction. It makes a comparison and then deposits the results into a register, rather than a status register.
>Also why do you need four read ports, wouldn’t you just break it into multiple cycles
I could do that, but I'd rather be able to do everything in a single cycle or pipeline the design.

>>1891324
>conditional instructions should compare against internal processor flags
>You'd get better overall performance
I'm actually trying to avoid a status register for performance and design reasons.
A status register isn't a big deal for single-cycle designs, but when you start getting into pipelined and out-of-order execution, the status register becomes kind of a forced data dependency and gets a lot more complicated.

Doing the comparison inside the branch instruction isn't that big of a deal for me since it only requires 3 reads (two registers to compare, and a branch target), which I already have for my base+offset store instructions.
Doing the comparison inside the branch should actually give a pretty good performance boost, since it removes the need for a prior comparison instruction and the data dependency between the comparison and branch instruction.
Based on the statistic that branches occur on average every 7 instructions or so, that should actually give a noticeable performance increase

>>1891517
it depends on what your target freq is and how many pipeline stages you intend on implementing i guess.

Generally speaking you'd get lower latency paths and better timing by splitting instructions and having comparison and other flags in dedicated flops (not mixed at all with your gp registers, and not indexed as gp registers).

>>1891523
True, it does mean that the branches take slightly longer to execute.
Once you get to the point of having multiple functional units in the pipeline though it's not quite as big of a deal, since you can have a dedicated branch unit.

>>1891517
You should be able to pipeline it still, you just have to stall the previous stages. This does result in an extra cycle for that instruction, but it’s still pretty low overhead compared to compare, possible branch, then execute, since you don’t have to flush the pipeline. What do your instruction encodings look like if your cmov can take 4 registers/ 3+ an immediate as params, are they fixed size or are you doing some more complex decoding?

>>1891322
Thanks for the suggestion. VHDL kind of can but it’s through a synthesis-tool-specific attribute which isn’t really portable or convenient. I haven’t looked at Verilog/SystemVerilog enough, but can you instantiate a component/module without connecting any ports and then refer/assign to it’s signals as compInstance.datain = xyz? I’m still trying to come up with other useful things that I could see how to implement. One would be translation time checking for CDC signals not going through a synchronization entity, though this would be less trivial than the others. Verilog seems much closer to the sort of syntax and features I want, but I’m hesitant to use a more lax type system.

>>1892183
only types worth using are verilog reg/sysverilog logic types.

That and structs made up of the above.

Also, from my experience on larger projects i have learnee that you should be very careful about mixing types on module boundaries. It may compile fine but be functionally completely wrong.

Like if you have 2 AXI structs, but both have certain axi signals in different orders in the struct - the compiler will simply treat them both as a big bit vector when connecting them, so you can get all kinds of wacky results

>>1892293
Interesting, does that appear in synthesis or simulation? I started an internship in June and I’ve learned a lot about the limitations of synthesis tools that I didn’t expect. Like they will make very bad assumptions with behavioral code if you’re not careful and will do things like create priority encoders when it could have been a mux or turn large combinational expressions into unbalanced trees that increase the propagation delay of combinational circuits unnecessarily. Also apparently for generates can produce shitty circuits in some instances but I haven’t seen that first hand since the company I work for doesn’t use them.

>>1892308
simulation, assume synth also.

You want to be as explicit as possible and keep things simple - leaving things and assuming the tools will infer what you want is very risky. You want to leave it with almost no choice so it doesnt fugg your shid up.

In designs that are actually going to fabrication, we only use basic types and types built up from them. No floats/reals/integers etc. Even though the tools *can* synthesise something doesnt mean that you should let them.

>>1890996
>>1891015
There's also https://github.com/asicguy/gplgpu

>>1892183
I have space to encode 3 source registers and one destination register.
Two of the sources may be an immediate value, and immediate values may either be short or long.
Short immediates just interpret the register select bits as the immediate value (5-bits), while long immediates are contained in the following word after the instruction.

I think I'm actually going to skip on adding register-register comparisons in the branch instructions and just go back to comparisons against zero like MIPS does.

>>1869424
>>1869772
Not him, but another example: MiStER FPGA All it really is, is a linux arm dev with a relatively big and fast FGPA onboard. The linux portion handles the IO, and pushing the compiled code to the FPGA so it knows what it is, and then the ROMs to the FPGA. I'm not sure if they compile from VHDL on the board itself, but it should be possible. Anyway, if you didn't have the linux portion there, you'd have to hook up a ton of external stuff to get it all ready.

Also for a lot of uses, you only want/need certain portions to be "in hardware", so you keep everything that doesn't need to be in software, to be more quickly and easily iterable.