azonenberg_work has quit [Ping timeout: 250 seconds]
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 250 seconds]
emeb has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
hughhalf has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
hughhalf has joined ##openfpga
Bike has quit [Quit: Lost terminal]
freemint has quit [Ping timeout: 250 seconds]
rohitksingh has quit [Ping timeout: 250 seconds]
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 245 seconds]
Jybz has joined ##openfpga
Jybz has quit [Ping timeout: 265 seconds]
rohitksingh has joined ##openfpga
happycube has quit [Ping timeout: 246 seconds]
Jybz has joined ##openfpga
Jybz has quit [Ping timeout: 240 seconds]
Mimoja8 has joined ##openfpga
rohitksingh has quit [Ping timeout: 250 seconds]
dkozel_ has joined ##openfpga
Mimoja has quit [Quit: Ping timeout (120 seconds)]
Ekho has quit [Remote host closed the connection]
dkozel has quit [Ping timeout: 245 seconds]
Ekho- has joined ##openfpga
SpaceCoaster has quit [Ping timeout: 240 seconds]
SpaceCoaster_ has joined ##openfpga
rohitksingh has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
rohitksingh has quit [Ping timeout: 250 seconds]
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 245 seconds]
mkru has joined ##openfpga
rohitksingh has joined ##openfpga
Asu has joined ##openfpga
freemint has joined ##openfpga
rohitksingh has quit [Ping timeout: 264 seconds]
m4ssi has joined ##openfpga
freemint has quit [Ping timeout: 276 seconds]
freemint has joined ##openfpga
indefini[m] has quit [Quit: 30 day idle timeout.]
mkru has quit [Remote host closed the connection]
freemint has quit [Ping timeout: 245 seconds]
freemint has joined ##openfpga
emeb_mac has joined ##openfpga
genii has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
carl0s has joined ##openfpga
<carl0s>
Hi, I have downloaded an verilog example https://pastebin.com/BLTkUeGy, is the last else really needed? please correct me if i'm wrong but i don't see any case of it being executed, maybe I am still thinking in software and not hdl.
<tnt>
no
<tnt>
But it's also a terribe example of verilog ...
<tnt>
posedge delay_1s is cringy ...
<tnt>
using non-clock signal as clock input of FF is really a special case that's best avoided unless you really know what you're doing.
<daveshah>
I'm pretty sure it's not even synthesisable (at least according to 1364.1, other tools might be more liberal)
<daveshah>
Because the "clocked actions" should appear in the final else - the clock shouldn't be in an "if"
<tnt>
looks like someone wrote vhdl ( if rising_edge(clk) ) in verilog ...
<carl0s>
Hi, I'm trying to fix it, it's a vendor example project
<daveshah>
Which vendor?
<carl0s>
Gowin
<carl0s>
California/china based i think
m4ssi has quit [Remote host closed the connection]
rohitksingh has joined ##openfpga
<carl0s>
https://pastebin.com/pyzcjtU9 , i haven't uploaded it to a fpga but what i assume this code does is toggle four leds every second, almost all always @ blocks being used to generate timing signals.
<daveshah>
With `posedge clk` in the sensitivity list it is fine
<daveshah>
That's the correct way to do low frequency events - use the divided signal as an enable
<carl0s>
I see, you mean the 'else if (delay_1ms)' statement, delay_1ms being the enable?
<hackerfoo>
Aren't async resets bad practice?
rohitksingh has quit [Ping timeout: 265 seconds]
<daveshah>
carl0s: yes, that's right
<daveshah>
hackerfoo: depends - you certainly have to be more careful with them
<daveshah>
and I think they're used much more often in the ASIC world
<hackerfoo>
I thinks it's best to only use "always @(posedge clk)" and "always @(*)" until you really need something else.
rohitksingh has joined ##openfpga
<carl0s>
hackerfoo, so i would need to check for rst_n inside the always block instead of using it on the sensitive list? Or does it depends if the FF on the LUTs of my device are or are not sync?
<hackerfoo>
carl0s: For a sync reset, you'd just remove `rst_n` from the sensitivity list. You have to act on the signal inside the block either way.
<carl0s>
True
<carl0s>
Well, learned a bunch of stuff about verilog today, i will try to simulate the design and synth it for a icestick i have laying around
<hackerfoo>
It's not really PWM, it's delta-sigma. You just output the carry bit of an adder for an accumulator.
<hackerfoo>
(Ignore the clock divider, It was a long time ago and I didn't know how to configure a clock slow enough.)
<carl0s>
When is the value of carry changed? when the sum of both pwm_count and count overflow?
<hackerfoo>
`carry` should be high every cycle that the addition overflows the width of `pwm_count`.
<carl0s>
Nevermind, just saw the pwm_count and count widths
<carl0s>
yep
<hackerfoo>
So if you have a `count` of all 1s, it should overflow almost every time, and never if `count` is 0.
<hackerfoo>
But unlike PWM, it will be dithered at the highest possible frequency, which means it'll be far less choppy at 50%.
<hackerfoo>
`pwm_count` should be called `error`, where it's holding the error in the duty cycle, which it corrects with each output pulse.
<hackerfoo>
That's how delta-sigma DACs work. It's really simple.
<hackerfoo>
And you could vary `count` (e.g. a sine wave) and the error counter should cause the duty cycle of `carry` to track it properly even if it changes faster than a full counter cycle.
<hackerfoo>
So it automatically handles the tradeoff between time resolution and accuracy.
<hackerfoo>
This also explains why delta-sigma DACs suffer outside of the middle 80% of their range, because the cycle gets longer before it repeats as you get near the edges.
<carl0s>
Hold on lol, so if i understand correctly `count` does a linear increment, so kind of a sawtooth signal, overflows and start again, and it does so while you are pressing the button
<hackerfoo>
Yeah, with some debouncing in there.
<hackerfoo>
That's how you set the brightness of the "analog" LED.
<carl0s>
does pwm_led inverts the LSbit of the carry register, isn't?
<carl0s>
that signal is your 'analog' led
<hackerfoo>
The pin is connected to the negative sice of the LED, so it lights up when low.
<hackerfoo>
Yeah
<hackerfoo>
The other LEDs show the value of `counter` for a little while.
<carl0s>
while `display_timer != 6'b0`
<hackerfoo>
I suppose I should clean this old code up.
<carl0s>
I'm overwhelmed by it lol
<hackerfoo>
Just forget everything but line 52, that's what I wanted to demonstrate.
freemint has quit [Ping timeout: 245 seconds]
rohitksingh has quit [Ping timeout: 250 seconds]
rohitksingh has joined ##openfpga
freemint has joined ##openfpga
carl0s has quit [Remote host closed the connection]
<lolsborn>
CHERI is an example of one of the cores https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ it has some novel properties that allow it to catch buffer overflow attacks and halt. Each TA1 team has their own uniqe open-source security addons
<lolsborn>
I just wanted to say hello as I've been following many of you on twitter and using tools that many of you wrote for sometime now. I'm a software developer with some experience in hardware design, but prety new to FPGAs so this has been an adventure so far.
<pie_>
(would be better to code in a way buffer overflows arent possible to begin with, but hey)
rohitksingh has quit [Ping timeout: 245 seconds]
<whitequark>
even in memory-safe languages, unsafe code exists, and compiler bugs exist too
<TD-Linux>
lolsborn, pretty cool! I assume you're going to use the generated verilog from the bluespec ones
* sorear
remembering a project they tried to start earlier this year
gnufan_home has joined ##openfpga
cpresser has quit [Remote host closed the connection]
_whitelogger has joined ##openfpga
Bike has joined ##openfpga
<lolsborn>
I'm using generated verilog for both processor types. The Rocket ones I could edit as the toolchain (scala) is open source, but the bluespec toolchain is closed (atleast right now).
<sorear>
is that likely to change?
<lolsborn>
I can't say anything official, but we've been working very closely with Bluespec :-) The TA1 teams seem to think BluSim seems pretty interesting and could provide an interesting alternative to verilator. It is 3-4x faster than Verilator for any of the cores tested on it.
<lolsborn>
Technical Area 1 - It's just a term for any of the 6 teams working on processors for this project
<TD-Linux>
lolsborn, interesting. do you think the increased speed is due to being able to emulate the higher level bluespec constructs?
<lolsborn>
ARM has already invested in CHERI (mentioned above) so these technologies are showing commerical interest already
<lolsborn>
I'm guessing that part of the speedup is because the sim was built with optimizations for the bluespec cores in mind from the beginning, but I've heard you can see similar results with other workloads, I don't know if that includes synth of raw verilog or stuff ported to bluespec (Haskell)
<sorear>
what does Haskell have to do with anything
<lolsborn>
bluespec is all Haskell, it's just a high level HDL generator like Migen or SpinalHDL
<sorear>
uh it has an independent grammar
<sorear>
the elaboration language is very close to H98, but it's not embedded
<sorear>
and with completely different syntax
<sorear>
has functional dependencies, does NOT have IO
<sorear>
I have the manual and the papers, have thought about trying to implement a compiler
<sorear>
doesn't seem like an insurmountable problem but I spent a month getting stuck on the Best Way to implement a parser
<sorear>
I miss when I could actually do things
<TD-Linux>
lolsborn, very interesting. I've never actually looked at verilator optimization because I've never been bottlenecked by it, but it would be fun to profile what parts it does poorly in comparison
Asu has quit [Remote host closed the connection]
<TD-Linux>
I didn't realize blusim was competitive as a general purpose simulator
<lolsborn>
Yeah, that's all way beyond my area of expertise, but I've heard good things about it.
gnufan_home has quit [Quit: Leaving.]
cpresser has joined ##openfpga
cpresser has quit [Client Quit]
cpresser has joined ##openfpga
unkraut has quit [Remote host closed the connection]